Re: wait code is fishy

On 11/08/2025 08:52, Denys Vlasenko wrote:
> 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.

I think this is misrepresenting what I was saying, and what the code is 
doing.

Currently, the code loops until it gets a result telling it there are no 
more processes that finished. You're suggesting looping as long as it 
gets a result telling it there *are* processes that finished. The 
difference is in the case where the shell got no information at all on 
whether a process finished, because the shell received a signal. You're 
suggesting (please correct me if I am misrepresenting what you meant) 
that because the shell received a signal, we already know that there are 
no more processes that finished, because any process that finished 
before the signal was received was handled already, and any process that 
finished after the signal was received is okay to ignore because the 
next attempt could have missed it anyway due to timing.

For processes that finish before the signal, and processes that finish 
after the signal, I agree. But those aren't the only situations: I'm 
pointing out that it's not only possible, but reasonable and common, 
that a process finished and the shell received a signal at exactly the 
same time. That is the situation that the code currently handles, that 
your proposed change would not handle.

Again though, I do not know the impact of handling or not handling that, 
so although I disagree with your rationale, the change itself may 
possibly still be fine.

Cheers,
Harald van Dijk