Re: busyloop in sigchld_handler

[David Kastrup <dak@gnu.org>]

Andreas Schwab <schwab@suse.de> writes:

> Sam Steingold <sds@gnu.org> writes:
>
>> 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.
>
> But the busyloop does not happen when there is nothing to do, it only
> happens when wait3 is interrupted.  A zero return will cause the handler
> to return immediately.
>
>> Now, it might be better to remove the WNOHANG option instead (except that
>> signal handlers are not supposed to hang),
>
> If you don't use WNOHANG you open up a race where several processes may
> have their status changed, but only one signal is sent (non-realtime
> signals are not queued).

How does WNOHANG protect against that?  It does not prevent
scheduling, and it certainly does not prevent parallel execution on
multi-processor machines.

I should think that we need to prepare against this anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum