When using ant to run windows applications in parallel, termination of one application will not always result in a new process. The problem can be verified on XP and Server 2003 with simple GUI hello world programs that pop up a window and have to be closed manually. I experienced it with Ant 1.65 and the current ant 1.7.0 nightly build (may 28th 2007), on both a P4 machine (with 2 virtual processors) and on a Xeon server with 4 processors. In the following script on a 2-processor machine, sometimes (25%-50% of the time) I have to close both HelloWorld1 and HelloWorld2 before HelloWorld3 is startet. The problem does not depend on which program is closed, it occurs sometimes if I close HelloWorld1 and sometimes if I close HelloWorld2. <parallel threadsPerProcessor="1"> <exec executable="HelloWorld1.exe"/> <exec executable="HelloWorld2.exe"/> <exec executable="HelloWorld3.exe"/> <exec executable="HelloWorld4.exe"/> </parallel> The same problem occurs if I enter a fixed threadCount. If I run the next code snippet, it is rare that a new application is startet if I terminate a randomly picked process of the 4 started process, often I have to close all 4 applications before the next 4 are started. <parallel threadCount="4"> <exec executable="HelloWorld1.exe"/> <exec executable="HelloWorld2.exe"/> <exec executable="HelloWorld3.exe"/> <exec executable="HelloWorld4.exe"/> <exec executable="HelloWorld5.exe"/> <exec executable="HelloWorld6.exe"/> <exec executable="HelloWorld7.exe"/> <exec executable="HelloWorld8.exe"/> </parallel> In fact, monitoring our Nightly Build which compiles a large number of C++ programs in parallel on a 4-processor machine showed that with threadsPerProcessor="1", sometimes only one process is running. This severely prolongs out build time, because the compile time of a few projects is very long and if ant waits for such a project then only one processor is used instead of all 4.
I am trying to analyze this issue, it seems like the stream pumper of the exec tasks hangs for quite some time.
*** This bug has been marked as a duplicate of 5003 ***