Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  ofv@wanadoo.es,  emacs-devel@gnu.org,
>   eller.helmut@gmail.com,  acorallo@gnu.org
> Date: Tue, 24 Dec 2024 07:03:53 +0100
> 
> (I've given this a new subject.)

Not a second too soon!

> This is about SIGCHLD, and I must say I find it a bit hard to tell if
> all other platforms do the same. There are simply too many #if's to
> consider in the signal handling code.
> 
> Anyway, what I see here: SIGCHLD doesn't do anything dangerous in the
> signal handler. Instead, the occurrence of SIGCHLD is added to a queue
> with enqueue_async_work and that's basically it.

Are we looking at the same code?  I was talking about
handle_child_signal, which is called thusly:

  static void
  deliver_child_signal (int sig)
  {
    deliver_process_signal (sig, handle_child_signal);
  }

What I see in handle_child_signal is not what you describe above.

> The work items in the queue are processed by process_pending_signals,
> outside of the signal handler. Very nice, that's how it should be :-).

I think you are looking at how SIGIO and SIGALRM are processed.

> (And maybe, just as an inspiration, one could use that construct for
> SIGPROF?)

Could one?  SIGPROF's handler should sample the "program counter", so
delaying the sample will sample it in a wrong place.  Right?