wide integer type from unsigned int (which managles as
a 'j') to an int (which mangles as an 'i'). This
change makes intel-darwin generated code match the
darwin toolset generated code.
Intel reports this won't be fixed in 10.1 because it's
an ABI breanking chanage so we won't see this patched
until the 10.2 compilers.
[SVN r44729]
wide integer type from unsigned int (which managles as
a 'j') to an int (which mangles as an 'i'). This
change makes intel-darwin generated code match the
darwin toolset generated code.
Intel reports this won't be fixed in 10.1 because it's
an ABI breanking chanage so we won't see this patched
until the 10.2 compilers.
[SVN r44729]
This was caused by the file_dirscan() function in the filent.c module not working correctly when passed '\' as its dir. It then messed up when formatting its file-selection parameter for the _findfirst()/findfirst() API and constructed it as '\/*' which caused that API to fail and return -1 which was in turn being interpreted as 'file not found'.
[SVN r44088]
This was caused by the file_dirscan() function in the filent.c module not working correctly when passed '\' as its dir. It then messed up when formatting its file-selection parameter for the _findfirst()/findfirst() API and constructed it as '\/*' which caused that API to fail and return -1 which was in turn being interpreted as 'file not found'.
[SVN r44088]
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.
[SVN r44087]
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.
[SVN r44087]
