Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 29 Dec 2024 20:44:07 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org
> 
> Here's a sketch.  The idea is that all signals go through the signal
> receiver thread, which serializes them, picks one, enters the arena,
> tells the main thread that this signal is now safe to run, re-kills the
> main thread, waits for confirmation, leaves the arena, waits for
> confirmation AGAIN, then goes back to sleep.

Is the "enters the arena, tells the main thread that this signal is
now safe to run" part so that we avoid the recursive arena lock, which
leads to crashes?  If so, having MPS implement a callback immediately
after it releases the arena lock will provide us with the same device,
just much simpler and without the need to have a separate thread,
re-killing, etc.  IOW, the idea is:

  . signal handler is called
  . if the arena is unlocked, it runs the handler's body
  . otherwise, it sets a flag to indicate the signal happens and exits
    - when the arena is unlocked, we are called, and run the handler's body

Does this do the same as what you wanted to achieve?

> However, the re-kill cannot happen just with the same signal, because we
> need to block that in the main thread, in the case of SIGCHLD

Didn't Gerd and/or Helmut already solve the SIGCHLD case by moving its
handler's body out of the signal handler?