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]
