Re: waiting for process substitutions

[Chet Ramey]

On 7/14/24 8:40 PM, Zachary Santer wrote:

> On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey <chet.ramey@case.edu> wrote:
> > There is code tagged
> > for bash-5.4 that allows `wait -n' to look at these exited processes as
> > long as it's given an explicit set of pid arguments.
>
> I agree with all the knowledgeable people here telling you that the
> way 'wait -n' is still implemented in bash-5.3-alpha is obviously
> wrong, but I also want to point out that the way you plan to change
> its behavior in bash-5.4 still won't allow Greg's example below to
> work reliably.

OK, but how would you do that? If a job has already terminated, and been
removed from the jobs list, how would you know that `wait -n' without pid
arguments should return it? There can be an arbitrary number of pids on
the list of saved pids and statuses -- the only way to clear it using wait
is to run `wait' without arguments.

You can say not to remove the job from the jobs list, which gets into the
same notification issues that originally started this discussion back in
January, and I have made a couple of changes in that area in response to
the original report that I think will address some of those. But once you
move the job from the jobs list to this list of saved pids, `wait' without
-n or pid arguments won't look for it any more (and will clear the list 
when it completes). Why should `wait -n' without pid arguments do so?

> On Fri, Jul 12, 2024 at 9:06 PM Greg Wooledge <greg@wooledge.org> wrote:
> > greg@remote:~$ cat ~greybot/factoids/wait-n; echo
> > Run up to 5 processes in parallel (bash 4.3): i=0 j=5; for elem in "${array[@]}"; do (( i++ < 
> > j )) || wait -n; my_job "$elem" & done; wait
>
> He'd have to do something like this:
> set -o noglob
> i=0 j=5
> declare -a pid_set=()
> for elem in "${array[@]}"; do
>    if (( ! i++ < j )); then
>      wait -n -p terminated_pid -- "${!pid_set[@]}"
>      unset pid_set[terminated_pid]
>    fi
>    my_job "$elem" &
>    pid_set[${!}]=''
> done
> wait
>
> It's probably best that 'wait -n' without arguments and 'wait -n' with
> explicit pid arguments have the same relationship to each other as
> 'wait' without arguments and 'wait' with explicit pid arguments.

That's pretty much what we're talking about here. `wait' without arguments
doesn't look in the list of saved statuses whether -n is supplied or not.
`wait' with pid argument should look in this list whether -n is supplied or
not. But see below for the differences between `wait' with and without pid
arguments whether -n is supplied or not.


> In other words, process substitutions notwithstanding,
> $ wait
> and
> $ wait -- "${all_child_pids[@]}"
> do the same thing.

That's just not true, and they're not even defined to do the same thing.
If you ask for a specific pid argument, wait will return its exit status
even if the job it belongs to has been removed from the jobs list and
saved on the list of saved pids and statuses. wait without pid arguments
just makes sure there are no running child processes and clears the list of
saved statuses -- it has no reason to look at the saved pid list before it
clears it.

> So,
> $ wait -n
> and
> $ wait -n -- "${all_child_pids[@]}"
> should also do the same thing.

One issue here is that wait without arguments clears the list of saved
statuses. `wait -n' without arguments doesn't do that, but it probably
should since it's now going to have access to that list, though it would
no doubt break some existing use cases.

The other issue is as above: why should `wait -n' with no pid arguments
do anything with processes on this list? And if you think it should, what
should it do with those processes?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature