silly mistakes like using a negative time for the select
timeout.
Also added the setrlimit call back in since the
named_condition_test occassionally consumes multiple cpus
worth of time. That is, when I ran this test -j4, I found
the named_condition test consuming 4 cpus worth of time so
after 300 seconds of elapsed time when the test timed out,
it had consumed almost 1200 seconds worth of cpu. While the
test is killed after the elapsed time expired, setting a hard
cpu limit ensures it's killed after consuming either -lx seconds
worth of cpu or -lx seconds of elapsed time.
[SVN r39613]
silly mistakes like using a negative time for the select
timeout.
Also added the setrlimit call back in since the
named_condition_test occassionally consumes multiple cpus
worth of time. That is, when I ran this test -j4, I found
the named_condition test consuming 4 cpus worth of time so
after 300 seconds of elapsed time when the test timed out,
it had consumed almost 1200 seconds worth of cpu. While the
test is killed after the elapsed time expired, setting a hard
cpu limit ensures it's killed after consuming either -lx seconds
worth of cpu or -lx seconds of elapsed time.
[SVN r39613]
seems that doxygen target now produces a target
with different name, and it does not produce
any target unless there's explicit dependency
on it. I'm not sure I like the change, but
anyway.
[SVN r39605]
seems that doxygen target now produces a target
with different name, and it does not produce
any target unless there's explicit dependency
on it. I'm not sure I like the change, but
anyway.
[SVN r39605]
Added an optimization to the -lx unix timeout code. I
compute the amount of time the select call should sleep
until the "oldest" process times out. This ensures that
all processes that timeout will be killed within one
second of their expiration.
[SVN r39534]
Added an optimization to the -lx unix timeout code. I
compute the amount of time the select call should sleep
until the "oldest" process times out. This ensures that
all processes that timeout will be killed within one
second of their expiration.
[SVN r39534]
Fixed problems with threading, pic code, missing math
library, etc. to get mipspro toolset working better.
Updated pgi toolset to fix various problems with the
link line.
[SVN r39531]
Fixed problems with threading, pic code, missing math
library, etc. to get mipspro toolset working better.
Updated pgi toolset to fix various problems with the
link line.
[SVN r39531]
The intel based darwin system was killing subprocesses
okay but for some reason, ppc systems were not. This
change fixes the timeout code so subprocesses are
properly killed on ppc darwin systems.
[SVN r39514]
The intel based darwin system was killing subprocesses
okay but for some reason, ppc systems were not. This
change fixes the timeout code so subprocesses are
properly killed on ppc darwin systems.
[SVN r39514]
sub-processes after bjam forks a new process (for example, after
g++ is forked by bjam, g++ then forks sub-processes like cc1plus).
The timeout code would kill the g++ process, but might not kill
the subprocesses spawned by g++.
I fixed this problem by making the bjam fork'ed process (g++) a
session leader by calling setsid() before calling exec. The setsid
call, in essence, gives all child processes a parent process id
(ppid) of the g++ process id. This guarantees that killing g++
will kill all child processes spawned by g++ as well.
One last comment on the maximum process time before a process is actually
killed. The worst case process elapsed time is 2x seconds if -lx is
given. The reason is that a process might be one second away from being
killed and, if there's no other signal activity, the select function will
wait x seconds before timing out and killing any active processes. So
if you say -lx and monitor a build known to have lengthy processes, you
may see a process with up to 2x seconds of time before it is killed.
[SVN r39467]
sub-processes after bjam forks a new process (for example, after
g++ is forked by bjam, g++ then forks sub-processes like cc1plus).
The timeout code would kill the g++ process, but might not kill
the subprocesses spawned by g++.
I fixed this problem by making the bjam fork'ed process (g++) a
session leader by calling setsid() before calling exec. The setsid
call, in essence, gives all child processes a parent process id
(ppid) of the g++ process id. This guarantees that killing g++
will kill all child processes spawned by g++ as well.
One last comment on the maximum process time before a process is actually
killed. The worst case process elapsed time is 2x seconds if -lx is
given. The reason is that a process might be one second away from being
killed and, if there's no other signal activity, the select function will
wait x seconds before timing out and killing any active processes. So
if you say -lx and monitor a build known to have lengthy processes, you
may see a process with up to 2x seconds of time before it is killed.
[SVN r39467]
