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 <[EMAIL PROTECTED]> 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.
Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thank you,
Chuck Holzwarth
(804) 403-3478 (home)
(540) 335-3171 (cell)
---------------------------------
Never miss a thing. Make Yahoo your homepage.
