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

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org,  phst@google.com, p.stephani2@gmail.com
> Date: Wed, 20 Jan 2021 11:17:24 +0100
> 
> On Jan 20 2021, Eli Zaretskii wrote:
> 
> > If/when the signal arrives, the handler removes the file descriptor of the 
> > process from the set on which pselect will wait.  Isn't that sufficient to 
> > prevent us from waiting for a dead process?
> 
> Who removes it?

The SIGCHLD signal handler.  Or I thought it did, here:

          /* If process has terminated, stop waiting for its output.  */
          if (WIFSIGNALED (status) || WIFEXITED (status))
            {
              bool clear_desc_flag = 0;
              p->alive = 0;
              if (p->infd >= 0)
                clear_desc_flag = 1;

              /* clear_desc_flag avoids a compiler bug in Microsoft C.  */
              if (clear_desc_flag)
                delete_read_fd (p->infd);  <<<<<<<<<<<<<<<<<<<<<<<<<
            }

But it looks like it only removes the process's file descriptor from
the set to be used for setting up arguments to pselect the _next_
iteration through the loop.

So maybe this is the problem we should solve: make the SIGCHLD handler
reset the bit of the process's output from the fd_set passed to
pselect.  Then, if SIGCHLD hits at any time before pselect is called,
it will not wait for output from that process.

> > If not, why not?
> 
> What happens when the signal occurs between setting up the set and
> calling pselect?

Yes, see above.

But it sounds like the situation shown in Philipp's log is different.