Re: SIGPROF + SIGCHLD and igc

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

No we aren't :-). My mistake. I was looking at he code Pip wrote.
See Helmut's later message and my response.

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

Taking the backtrace would be done in the signal handler, the rest would
be done elsewhere. So, no.