Re: busyloop in sigchld_handler

[Sam Steingold <sds@gnu.org>]

Andreas Schwab wrote:
> Sam Steingold <sds@gnu.org> writes:
> 
>> Andreas Schwab wrote:
>>> Sam Steingold <sds@gnu.org> writes:
>>>
>>>> wait3 is a system call, which, when invoked in a loop, prevents the
>>>> kernel from doing anything else (in this case, sending SIGCHLD to
>>>> emacs). sleep allows the kernel some time to pass the signal.
>>> I don't find this explanation convincing at all.  Since the system call is
>>> made _inside_ the signal handler, the signal is actually blocked here, so
>>> it cannot be delivered anyway.
>> yes, you are right.
>> what I should have said was that by making a system call in a busyloop,
>> emacs prevents the kernel from doing what it needs to do to the the child
>> so that wait3 will succeed.
> 
> What does the kernel have to do?  The EINTR error will only happen when
> the system call was interrupted _and_ a signal handler was called.

I don't know the details, but the kernel obviously has to do SOMETHING 
when the child process terminates: it has to notice the state change so 
that wait3 in emacs will return "yes, the child is dead" instead of 
"nothing for you yet". The busyloop prevents the kernel from doing 
anything for some time.

Now, it might be better to remove the WNOHANG option instead (except 
that signal handlers are not supposed to hang), or use usleep(10000) 
instead of sleep(1), but the busyloop is what has to be fixed.

Please also note that I am not in any way an expert in kernel matters.

Sam.