Re: Parallel processing

[Philippe Troin <phil@fifi.org>]

On Sat, 2022-03-26 at 15:19 -0700, Bart Schaefer wrote:
> On Sat, Mar 26, 2022 at 11:10 AM Philippe Troin <phil@fifi.org> wrote:
> 
> 
> > Anyways, zargs is not doing a stellar job currently with collecting
> > exit statuses from commands ran in parallel:
> 
> # Everything has to be in a subshell just in case of backgrounding jobs,
> # so that we don't unintentionally "wait" for jobs of the parent shell.
> 
> Hmm ... zargs uses
>   wait ${${jobstates[(R)running:*]/#*:/}/%=*/}
> to wait for all the backgrounded jobs that it started.  (This causes a
> segfault in the most recent git checkout if zargs itself is a subshell
> job.)  However, that "wait" returns the exit status of only one of
> those jobs.  There might be something more that could be done now, to
> pick up the status of the rest ... but I'm reluctant to mess with that
> while the segfault is unfixed.
> 
> >    % zargs -n 4 -P 2 -- 0 1 -- zsh -c 'sleep $1 ; exit $1 ' -; echo $?
> >    123
> 
> This is explained in the comments in zargs:
> 
> # Like xargs, zargs exits with the following status:
> #   0 if it succeeds
> #   123 if any invocation of the command exited with status 1-125
> #   124 if the command exited with status 255
> #   125 if the command is killed by a signal
> #   126 if the command cannot be run
> #   127 if the command is not found
> #   1 if some other error occurred.

I was referring to the fact that zargs misses the exit status of
subcommands:

   % zargs -n 4 -P 2 -- 1 0 -- zsh -c 'sleep $1 ; exit $1 ' -; echo $?
   0
   % zargs -n 4 -P 2 -- 0 1 -- zsh -c 'sleep $1 ; exit $1 ' -; echo $?
   123

Both zargs invocation will spawn two subcommands.  In both cases one
subcommand will exit with status 0 and the other with status 1.

In the first invocation, zargs misses that one of the subshells returns
non-zero exit status.

Phil.