Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 01 Jul 2024 17:27:49 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org
> 
> > It goes without saying that updating a static data structure makes the
> > signal handler non-reentrant, and it should at least block SIGCHLD.
> 
> Blocking SIGCHLD in a SIGCHLD handler is redundant unless SA_NODEFER is in use. Are we talking about a different handler here?

First, that queue was intended for more than just SIGCHLD.

And second, depending on the OS, nested signals can or cannot be
possible, so we need to take that into consideration.

> One last suggestion: how about blocking those signals for most of Emacs' lifetime, only unblocking them in maybe_quit or at similar points? That would allow us to keep the existing signal handlers and make them safe...

IMO, this would be the opposite of what we should do.  We should have
these signals blocked for as little time as possible, because
otherwise the features built on them will be much less useful.  For
example, SIGUSR1/2 are a means of forcing Emacs out of some infinite
loop which is otherwise uninterruptible -- if we let these signals be
unblocked only in maybe_quit, we will have lost this useful feature.

Which is why I suggested to block the signals before calling MPS and
unblock them immediately when we return from an MPS call.  All of
these calls are in igc.c, so the job of adding these blocks, while
mundane and boring, is not impossible.

But if people who have time to work on that disagree, I have no means
of making them do what they don't agree with.

> I still think this is a simple oversight on the part of MPS, FWIW. You shouldn't allow other signals when handling SIGSEGV, or at least give the client program an option to specify a signal mask.

That's not the problem, AFAIU.  The problem is that a signal handler
which accesses Lisp data or the state of the Lisp machine could
trigger an MPS call, which will try taking the arena lock, and that
cannot be nested, by MPS design.  And our handlers do access the Lisp
machine, albeit cautiously and as little as necessary.  So when the
signal happens in the middle of an MPS call which already took the
arena lock, we cannot safely access our data.