Changeset 44087

Timestamp:

Apr 7, 2008, 9:55:18 AM (15 years ago)

Author:

Jurko Gospodnetic

Message:

Solved the problem with child process returning the value 259 (Windows constant STILL_ACTIVE) 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 (​http://msdn2.microsoft.com/en-us/library/ms683189(VS.85).aspx) warns about this problem.

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.

(No files)