Re: `wait -n` returns 127 when it shouldn't

[Chet Ramey]

On 5/18/23 7:51 AM, Robert Elz wrote:

> Apparently, in bash, if the code is running in a (shell) loop (like inside
> a while, or similar, loop) then each iteration around the loop, any jobs that
> have exited, but not been cleaned already, are removed from the queue (the
> jobs table in practice, though bash may also have something else).
>
> That's really broken, and should be fixed (but has apparently been that
> way for decades, and no-one noticed).

This isn't a problem, and is a red herring. The code that manages that list
makes sure to keep as many jobs in the list as POSIX requires, subject to
the maxchild resource limit.


> In the script in question, the offending loop isn't the one in the main
> program - in that for each iteration the background processes are started,
> and waited for, in each iteration, but the one in the waitjobs function.
> which (appears at first glance, which is all the analysis shells ever do)
> to be an infinite loop, so each time around, if there are any completed
> jobs in the table, they're removed. 

No, this isn't what happens. The problem is that the shell reaps both jobs,
but the `wait -n' code had a race condition that prevented it from finding
a job in the list.

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