[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: scratch/sigchld-fd 8f0ce42 1/2: Fix deadlock when receiving SIGCHLD during 'pselect'.
Date: Wed, 20 Jan 2021 17:30:53 +0200

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]