ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Holzwarth <>
Subject Re: extended parallelism
Date Tue, 18 Dec 2007 18:50:35 GMT
Perhaps the facility that spawns the targets could manage the screen/buffer output. This would
mean that some facility would have to exist similar to named pipes in Unix. This way, console
output would be directed from the buffer (or pipe) that had first output while other targets
would be producing output that could be buffered or spooled to disk (high volume of output)
for later display. A GUI that would be integrated would possibly have access to the streams
in a windowed type display but the end result should probably display the console format even
if views of the running thread outputs are allowed.

How would antform be handled?

Klaus Malorny <> wrote: Chuck Holzwarth wrote:
> [...]
> How do you propose to handle potential fatal/non fatal errors? If target a
> exits due to an error, should there be an option to kill a or allow it to
> complete (similar to failonerror="yes/no")? If both a and (b,c) must succeed
> for d, should a be killed if b or c fails? That would indicate a method
> (stack, shared memory, etc.) for tracking the result of the sub processes.
 > [...]

Hmm, good question.

Maybe if one target fails, no new targets shall be started, but already running 
targets shall be completed. Since they are obviously independent, it should not 
hurt to complete them. And it would mostly resemble the behaviour of the single 
threaded execution. If the running targets could be terminated gracefully, e.g. 
stopping them after the completion of the currently executed task, it would be 
nicer, of course. If you mean this by word "kill", this would be acceptable 
IMHO. However, the "hard way", like "Thread.stop" or even a kill on OS level is 
likely not a good idea.

On the contrary, one could add a "greedy" option, which tries to finish as many 
targets as possible. However I don't see a real benefit at the moment, as it 
would increase the turn-around time and would therefore be counter-productive.

Output handling is surely another important and difficult thing. From a user's 
perspective, it would be most convenient if the output of a target would remain 
in one piece. While a GUI could handle this more or less easily, console output 
is a bit tricky, though. The target which is the first to create some output 
would "own" the console, all others have to buffer theirs until this target has 
been completed.


To unsubscribe, e-mail:
For additional commands, e-mail:

Thank you,
Chuck Holzwarth
(804) 403-3478 (home)
(540) 335-3171 (cell)
Never miss a thing.   Make Yahoo your homepage.
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message