Re: wait -n misses signaled subprocess

[Chet Ramey]

On 1/29/24 3:49 PM, Robert Elz wrote:
>      Date:        Mon, 29 Jan 2024 12:07:53 -0500
>      From:        Chet Ramey <chet.ramey@case.edu>
>      Message-ID:  <fe9aafeb-673d-494a-9c82-2b81b67c1373@case.edu>
>
>    | What does `wait -n' without job arguments mean?
>
> Find, or if there are none already, wait*(2) for, a process (job technically)
> that has changed state (terminated in POSIX, and one day in the NetBSD
> shell, that difference isn't relevant here) and return its status.
> If there's already a terminated job (job which has changed status in bash)
> then no wait type sys call gets performed (that already happened).

That was mostly a rhetorical question, since this was the way -n worked
orginally, before it started paying attention to pid arguments.

Implicit here is the notification/changed state issue we've been
discussing.

> It also returns the status of that process, rather than simple "0" which
> a bare "wait" does (and with the appropriate arg, tells you which process
> it was).

Not originally, but -p var was a useful addition.

>    | OK. Since wait without options can already wait for the same pid multiple
>    | times, the -n option has to bring some new functionality here.
>
> Yes, without args, it waits until all listed arg processes (jobs) are
> finished (or changed state) and returns the status of the last.   With -n
> it waits for any one of them, just as the bash man page says it will.
> The "any one" (vs "all") is the new functionality.

Right -- it works on the list of running background jobs.

>    | As long as it's still in the jobs list.
>
> Yes, of course - the final para of my message covered that case.
>
>    | OK. We can agree there shouldn't be any difference between `wait pid'
>    | and `wait -n pid'.
>
> Yes, but just because that's a degenerate case of the more general commands,
> which happens in each case to devolve into the same thing.

Add more `pid' arguments, if you like. The real question is whether or not
we should extend `wait -n' to behave more like `wait' without options.

> And from a different message:
>
> chet.ramey@case.edu said:
>    | So should the shell require the user to periodically run `wait' in a non-
>    | interactive shell without job control to clean dead jobs out of the jobs
>    | list? I don't think so.
>
> I do.   wait or jobs ("jobs >/dev/null" is a nice simple clean up, without
> the potential hang waiting for things to terminate that the wait utility
> imposes). 

Why impose that requirement when it's never existed before? If you want to
do it, go ahead, but we shouldn't be making that a requirement now.

  A new option to wait(1) (either a simple one, perhaps -t, to
> only wait for already terminated jobs,

Bash `wait' already has -f to return only when the specified job(s) has
terminated, reserving -t for some future use.

> Of course, you're also allowed to dump processes from the lists if there
> get to be too many of them, but on modern systems, it really should be
> possible to retain hundreds, if not thousands, without any real problem.

There's no reason to keep thousands of terminated jobs in the jobs list,
slowing everything down, as long as you give users a way to retrieve their
status.


> It's also a bit unusual for non-interactive code to run lots of async jobs
> without waiting for results - doing that is a sure way to run into the
> "max user processes" limit, and have things start failing.  

You can run thousands of background jobs in a loop without exceeding the
max process limit. People doing that is what got us here in the first
place.

Chet

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