Re: SIGPROF + SIGCHLD and igc

[Daniel Colascione <dancol@dancol.org>]

On December 30, 2024 12:47:36 PM EST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 30 Dec 2024 16:46:20 +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
>> 
>> We can't avoid re-killing because we might be on another thread.
>
>If we are on another thread, we know that, and can delay running the
>body.  Or we could just run the body (all the signal handlers we have
>that I know about don't care: MS-Windows already does that).  So this
>problem doesn't exist in practice, IME.
>
>> We shouldn't avoid it because we want signal handlers to be called
>> in signal handler context, not as C functions.
>
>Actually, no, we have no problems running the handlers we have as C
>functions.  Again, the MS-Windows build does that for years.
>
>> >   . signal handler is called
>> >   . if the arena is unlocked, it runs the handler's body
>> 
>> (BTW, if we're going for POSIX-conforming solutions, we can't call
>> pthread_mutex_trylock in a signal handler.
>
>We do it today, because that's how MPS crashes us.  So yes, we can do
>that.
>
>> >   . otherwise, it sets a flag to indicate the signal happens and exits
>> 
>> Which retriggers the signal
>
>No, it doesn't.  Again, we already have signals whose handlers behave
>like that.
>
>> >     - when the arena is unlocked, we are called, and run the handler's body
>> 
>> Do you mean "run the handler's body" or "try again"?  I'm not sure
>> running it unconditionally is safe, so I'd prefer to "try again",
>> re-establishing a signal handler context by unblocking the signal and
>> re-killing the main thread (even if that's us).
>
>I see no reason why it would be unsafe to just run it.  Again, our
>handlers are simple and usually do very little (SIGCHLD is a possible
>exception, but we already have a solution for it, AFAIU).
>
>> We can't run another thread's signal handler.
>
>Not in general, but in practice in Emacs we can (and do).
>
>> Again, I think this is a good idea, but I'd use it as an improvement to
>> the current protection code, not to replace it.
>
>I think you are over-complicating things because you are looking for a
>110% waterproof solution that would work for arbitrary code in the
>handler.  But we don't need such perfection, as the existing practices
>show.
>

The code there TODAY might not need to be "waterproof", but someone might add logic one day that violates the unstated simplifying assumptions on which you're relying. In this case, we'll end up with subtle and hard to diagnose race conditions. Better to make the mechanism robust from the start. Trying to take shortcuts with POSIX signals is penny wise and pound foolish.