bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: alex xmb ratchev
Subject: Re: `wait -n` returns 127 when it shouldn't
Date: Mon, 22 May 2023 11:01:57 +0200

On Mon, May 22, 2023, 07:43 Aleksey Covacevice <aleksey.covacevice@gmail.com>
wrote:

> On Thu, May 18, 2023 at 3:07 PM Chet Ramey <chet.ramey@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.
>

maybe the , race condition , is & bash code not registering the new thread
fast enuff

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    chet@case.edu
> http://tiswww.cwru.edu/~chet/
> >
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]