Re: wait code is fishy

On 8/11/25 03:21, Harald van Dijk wrote:
> On 10/08/2025 22:30, Denys Vlasenko wrote:
>> The reason for "pid == 0" retrying NONBLOCK wait for more processes
>> is unclear: if we got here, we already did wait for processes
>> just now, got none, waited for signals and got a not-SIGCHLD one,
>> so there should not be more processes to wait for.
>> A comment explaining it would be nice?
> 
> A signal that gets sent to a process group can simultaneously be> a nonfatal signal to the shell, and a fatal signal to the child,> where the nonfatal signal to the shell may get processed by
> the shell before the SIGCHLD resulting from the fatal signal> to the child. I do think it's possible for that extra> loop iteration to find more processes that have terminated.
>
> Whether this is an important case to handle, I do not know.

Of course any additional iteration of wait3(WNOHANG) has a chance
of finding more processes exited or stopped.

But by this logic, we may as well decide to do seventeen
iterations of it, not two.

It makes more sense to do the minimum number of iterations
required for correct behavior.

Consider that the addition of DOWAIT_WAITCMD_ALL flag
(the "jobs: Only block in waitcmd on first run" commit)
was needed exactly because in waitcmd() -> dowait() case,
dowait() is doing an unnecessary second wait3()
instead of letting waitcmd to check whether it is necessary
to wait more.

Now, with the DOWAIT_WAITCMD_ALL, it still does
the unnecessary second wait3(), it's just not causing
a potential buggy behavior (hang) because it's now doing
wait3(WNOHANG).