Re: SIGPROF + SIGCHLD and igc

[Eli Zaretskii]

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