Re: 'wait -n' with and without id arguments

[Zachary Santer]

BASH_VERSION now says "5.3.0(1)-beta", so it seems like a fair time to
test again:

$ source ./wait-n-failure

$ wait-n-failure::main
Reliable.

$ wait-n-failure::main explicit_pids
Reliable.

$ wait-n-failure::main monitor
Still loses a few concurrent processes each time. Most often 5, which
is interesting.

$ wait-n-failure::main monitor posix
Reliable.

$ wait-n-failure::main monitor notify
Still really bad.

$ wait-n-failure::main monitor posix notify
Also really bad.

$ wait-n-failure::main explicit_pids monitor posix notify
Often loses a process or two. Sometimes stops after only waiting for one.

On Tue, Sep 17, 2024 at 2:46 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 9/9/24 10:45 AM, Zachary Santer wrote:
>
> >> He wants interactive shells to notify the user less frequently about job
> >> status changes so `wait -n' works better.
> >
> > That's one option, but not my preferred option. I'll attempt a tl;dr:
>
> Stipulating that this is for interactive shells only.
>
> >
> > A) Solve 'wait -n' inconsistency through changes to job status notification:
>
> Pretty non-specific, but I assume you want notifications to behave like
> POSIX specifies in the latest version of the standard.

The longer email had a couple different options for how notifications
could behave. both of which could've been POSIX-conformant. I won't
pretend to understand the finer details of what POSIX specifies there.
It looks like you'd already taken option 2), more or less, by the time
I sent that email. If you're not going to make 'wait -n' without id
arguments pull something from the bgp list, then the 'set -o posix'
notification behavior ought to be made the default behavior, yeah.

> > - Would require more user-facing changes to bash's behavior in default mode
> > - Potentially more difficult to implement correctly
> > - Would leave some loose ends that would just have to be documented in
> > the man page
>
> Like `set -b'?

Yeah, that really needs to be mentioned explicitly. If the default
notification behavior stays as is, it should also mention that 'wait
-n' without id arguments in the interactive shell, with 'set -m'
enabled, requires that 'set -o posix' be enabled as well, for reliable
behavior. I could see putting all that in the BUGS section.

Maybe reference the BUGS section from appropriate points in the
manual. I know I never looked at it before I got burnt the first time.

> > B) Solve 'wait -n' inconsistency by allowing it to act on the list of
> > saved pids and statuses of jobs whose termination has already been
> > notified to the user:
> > - POSIX doesn't agree with the existence of that list
>
> POSIX says everything should disappear when you get notified or the
> subject of `wait', so there's that (bash just does it on `wait'). Those
> semantics have defenders just as ardent as you are.

Maybe those defenders can elucidate what purpose that behavior would serve.

At the end of the day, B) is by far the simpler solution, and wouldn't
leave a bunch of configurations where 'wait -n' doesn't really work
quite right in the interactive shell.

> > - 'set -o posix' exists so bash's default behavior can differ from
> > that specified by POSIX when POSIX is wrong-headed
> > - now I think 'wait' with id arguments should clear those ids and
> > statuses from the list of notified jobs, which does increase the
> > user-facing changed behavior a bit
>
> That's more POSIX semantics, and it's already implemented in posix mode.
> You have to do that anyway, to avoid handing back the same pid repeatedly
> when `wait -n' is called.

I wouldn't be against both A) and B) being implemented.

https://lists.gnu.org/archive/html/bug-bash/2024-09/msg00014.html
I know that was a long email, but I put a lot of time into that.

wait-n-failure
Description: Binary data