On Thu, May 18, 2023 at 3:07 PM Chet Ramey <chet.ra...@case.edu> wrote: > > 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. >
I fail to see where the race condition in `true & wait -n` is. Whether the 'underlying function' has a race condition is the true red herring here. Also, the manual states: 'If the -n option is supplied, wait waits for a single job from the list of ids or, if no ids are supplied, any job, to complete and returns its exit status.' `true & wait -n` returning 127 means `wait -n` did not wait for 'any job'; in fact, it waited for no job. The subsequent part about 'unwaited-for' children is either irrelevant or contradictory to the above given the current scenario. > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ >