Re: scratch/sigchld-fd 8f0ce42 1/2: Fix deadlock when receiving SIGCHLD during 'pselect'.

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 19 Jan 2021 19:21:39 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>, Philipp Stephani <phst@google.com>
> > In general, pselect is supposed to return with EINTR when SIGCHLD
> > happoens while we are inside the call to pselect, and EINTR seems to
> > be already handled by wait_reading_process_output.  So I wonder why we
> > need that additional "self-pipe" to be watched by pselect.
> 
> Yes, I'm wondering about that as well, but it's definitely the
> behavior I see. Before commiting to master, I ran the test
> process-tests/fd-setsize-no-crash/make-process multiple times with and
> without the commit, and the outcome was clear: without the commit
> accept-process-output would frequently hang, with the commit it never
> hangs.
> This is pure speculation, but I could imagine multiple things going on:
> - Maybe there's no guarantee that pselect actually returns EINTR on SIGCHLD.
> - Maybe EINTR is returned too early, before the signal handler got the
> chance to update the process status.

I'd be happier if we had some direct evidence to these effects.  I'd
also be surprised to hear that pselect doesn't return with EINTR when
SIGCHLD comes in.  It is more likely that SIGCHLD is delivered before
we call pselect, but if that is the case, we should be able to
reliably detect that, I think.

> > In addition, AFAIU this pipe should not be needed on MS-Windows, where
> > the pselect emulation waits on the sub-process handles together with
> > the other file descriptors, and so gets awakened when a process exits
> > or dies.  But again, without knowing the exact situations against
> > which this changeset tries to protect, it is hard to make a decision.
> 
> It's definitely not needed on Windows, which has a superior mechanism
> anyway (process handles are waitable objects in Windows). I opted to
> create the additional pipe on Windows as well - the costs should be
> small, and it keeps the code more consistent between the operating
> systems.

The thing is, on Windows we can only wait on up to 64 handles (unless
we complicate the code with multilevel wait, that is), so every
unnecessary descriptor we need to wait on means we can support fewer
simultaneous subprocesses.  We are already limited to just 32
subprocesses, which is quite low a number.