From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-04-02 05:33:02
> Solved the problem with child process returning the value 259 causing
> bjam never to detect that it exited and therefore keep running in an
> endless loop. Done by relying on the Windows WaitForMultipleObjects()
> function to detect when a process has exited instead of
> GetExitCodeProcess(). The later function's MSDN article warns about this
> Solved the problem with bjam going into an active wait state, hogging
> up processor resources, when waiting for one of its child processes to
> terminate while not all of its available child process slots are being
> used. To see this bug in action, try compiling a simple C++ program on a
> 2 processor PC with the -j 2 command-line option and watching how much
> processor resources bjam uses while linking. Was caused by treating
> unused process slots as used in the try_wait() function, causing the
> WaitForMultipleObjects() Windows API call to exit instantly with an
> error which was then getting incorrectly interpreted as a timeout,
> starting the whole cycle anew.
> Solved a race condition between bjam's output reading/child process
> termination detection and the child process's output
> generation/termination which could have caused bjam not to collect the
> terminated process's final output
> Extracted all GetExitCodeProcess() API calls into one location so it
> no longer gets called in three separate places.
> Minor comment changes in code touched by previous fixes.
I'm just pinging to see if now that Boost 1.35 is out someone could
review this patch and either apply it or tell me to apply it. I've had
it applied in my sandbox and have been actively using it on two
multi-processor development machines since posting the patch here and
there have been no problems.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk