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

[Eli Zaretskii]

> Date: Sat, 16 Jan 2021 13:49:49 -0500 (EST)
> From: p.stephani2@gmail.com (Philipp Stephani)
> 
> branch: scratch/sigchld-fd
> commit 8f0ce42d3eb9b212424a4a25a376287ffc94a73e
> Author: Philipp Stephani <phst@google.com>
> Commit: Philipp Stephani <phst@google.com>
> 
>     Fix deadlock when receiving SIGCHLD during 'pselect'.
>     
>     If we receive and handle a SIGCHLD signal for a process while waiting
>     for that process, 'pselect' might never return.  Instead, we have to
>     explicitly 'pselect' that the process status has changed.  We do this
>     by writing to a pipe in the SIGCHLD handler and having
>     'wait_reading_process_output' select on it.
>     
>     * src/process.c (child_signal_init): New helper function to create a
>     pipe for SIGCHLD notifications.
>     (child_signal_read, child_signal_notify): New helper functions to
>     read from/write to the child signal pipe.
>     (create_process): Initialize the child signal pipe on first use.
>     (handle_child_signal): Notify waiters that a process status has
>     changed.
>     (wait_reading_process_output): Make sure that we also catch
>     SIGCHLD/process status changes.
>     
>     * test/src/process-tests.el
>     (process-tests/fd-setsize-no-crash/make-process): Remove workaround,
>     which is no longer needed.

Philipp, can you please elaborate about this changeset (which was in
the meantime merged with master)?  The comments you added mention some
kind of deadlock, but don't describe what kind and in which situations
it could happen, and without that it's hard to understand what
problem(s) it tries to solve.

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.

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.

Thanks.