On 7/14/24 8:40 PM, Zachary Santer wrote:
On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey <chet.ra...@case.edu> wrote:There is code tagged for bash-5.4 that allows `wait -n' to look at these exited processes as long as it's given an explicit set of pid arguments.I agree with all the knowledgeable people here telling you that the way 'wait -n' is still implemented in bash-5.3-alpha is obviously wrong, but I also want to point out that the way you plan to change its behavior in bash-5.4 still won't allow Greg's example below to work reliably.
OK, but how would you do that? If a job has already terminated, and been removed from the jobs list, how would you know that `wait -n' without pid arguments should return it? There can be an arbitrary number of pids on the list of saved pids and statuses -- the only way to clear it using wait is to run `wait' without arguments. You can say not to remove the job from the jobs list, which gets into the same notification issues that originally started this discussion back in January, and I have made a couple of changes in that area in response to the original report that I think will address some of those. But once you move the job from the jobs list to this list of saved pids, `wait' without-n or pid arguments won't look for it any more (and will clear the list when it completes). Why should `wait -n' without pid arguments do so?
On Fri, Jul 12, 2024 at 9:06 PM Greg Wooledge <g...@wooledge.org> wrote:greg@remote:~$ cat ~greybot/factoids/wait-n; echo Run up to 5 processes in parallel (bash 4.3): i=0 j=5; for elem in "${array[@]}"; do (( i++ < j )) || wait -n; my_job "$elem" & done; waitHe'd have to do something like this: set -o noglob i=0 j=5 declare -a pid_set=() for elem in "${array[@]}"; do if (( ! i++ < j )); then wait -n -p terminated_pid -- "${!pid_set[@]}" unset pid_set[terminated_pid] fi my_job "$elem" & pid_set[${!}]='' done wait It's probably best that 'wait -n' without arguments and 'wait -n' with explicit pid arguments have the same relationship to each other as 'wait' without arguments and 'wait' with explicit pid arguments.
That's pretty much what we're talking about here. `wait' without arguments doesn't look in the list of saved statuses whether -n is supplied or not. `wait' with pid argument should look in this list whether -n is supplied or not. But see below for the differences between `wait' with and without pid arguments whether -n is supplied or not.
In other words, process substitutions notwithstanding,
$ wait
and
$ wait -- "${all_child_pids[@]}"
do the same thing.
That's just not true, and they're not even defined to do the same thing. If you ask for a specific pid argument, wait will return its exit status even if the job it belongs to has been removed from the jobs list and saved on the list of saved pids and statuses. wait without pid arguments just makes sure there are no running child processes and clears the list of saved statuses -- it has no reason to look at the saved pid list before it clears it.
So,
$ wait -n
and
$ wait -n -- "${all_child_pids[@]}"
should also do the same thing.
One issue here is that wait without arguments clears the list of saved
statuses. `wait -n' without arguments doesn't do that, but it probably
should since it's now going to have access to that list, though it would
no doubt break some existing use cases.
The other issue is as above: why should `wait -n' with no pid arguments
do anything with processes on this list? And if you think it should, what
should it do with those processes?
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
