Re: wait -n misses signaled subprocess

[Chet Ramey]

On 1/30/24 9:11 AM, Steven Pelley wrote:
> > > It does look in the table of saved exit statuses, returning 1.
> >
> > It doesn't. In this case, the code path it follows marks the job as dead
> > but doesn't mark it as notified (since it exited normally), so it's still
> > in the jobs list when `wait -n' is called, and available for returning.
> > That's probably a bug there.
>
> Got it.  So wait -n is intended to behave just as the documentation
> says -- "next" job -- and if there's a bug it's with how
> normally-exiting processes are handled, not signal-exiting processes.
> Thank you for your patience.

This has raised several other questions: whether `wait -n' should work
more like `wait' (see below) and whether non-interactive shells without
job control enabled should be so aggressive at marking jobs as notified,
since it's that state that allows them to move to the list of terminated
processes.

> > > There's also an interaction in that "wait" will only look at the
> > > terminated table if "-n" is not specified *and* ids are specified.
> >
> > This is to maintain POSIX semantics, with extensions. This is one of the
> > issues -- should `wait -n' with arguments look for terminated processes
> > in that table, the way `wait' without options does?
>
> Yes, I do want wait -n to look in the terminated table, at least for
> my use case responding to jobs finishing, one at a time, as soon as
> possible. 

OK. Can you think of a use case that would break if wait -n looked at
terminated processes?


> I _don't_ want bash to maintain some sort of internal state about
> which jobs have and haven't been returned by wait -n, which would be
> complicated and brittle (this is what my mental model was).  I'd want
> it to look in  the terminated table for finished jobs amongst the
> provided list of pids, and then I'd manage the list of pids myself,
> removing pids that were previously returned from wait -n.  This is a
> change in semantics and might introduce inconsistencies and difficulty
> implementing, I'm just describing what I think would be useful for my
> specific needs.

It's not difficult to implement.

--
``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