Stefan Beller <sbel...@google.com> writes:
> * If you do not die() in start_failure_fn or return_value_fn, you
> don't want to write to stderr directly as you would destroy the fine
> ordering of the processes output. So make the err strbuf available in
> both these functions, and make sure the strbuf is appended to the
> buffered output in both cases.
Another thing I noticed after re-reading the above is that we shared
the thinking that dying in these is _the_ normal thing to do and
continuing is an advanced and/or wierd setting.
And I think it is wrong. Suppose after spawning 15 tasks and while
they are still running, you start the 16th one and it fails to stop.
If your start-failure called die() to kill the controller, what
happens to the 15 tasks that are already running?
I think two sensible choices that start-failure and return-value can
make are
(1) This one task failed, but that is OK. Please let the other
tasks run [*1*].
(2) There is something seriously wrong with the whole world and I
declare an emergency. Please kill the other ones and exit.
Dying in these callbacks do not achieve neither. Perhaps make these
two functions return bool (or enum if you already know a third
sensible option, but otherwise bool is fine and the person who
discovers the need for the third will turn it into enum) to signal
which one of these two behaviours it wants?
And the default handlers should stop dying, of course.
[Footnote]
*1* Because start-failure gets pp, it can even leave a note in it to
ask the next invocation of get-next to retry it if it chooses
to. At this point in the design cycle, all we need to do is to
make sure that kind of advanced usage is possible with this
parallel-run-command API.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
