Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 03 Jul 2024 11:31:48 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org
> 
> So what are the proposed solutions that are still on the table? I can think of these:
> 
> 1. block signals around MPS calls and block signals while the MPS SIGSEGV handler is running
> 2. handle signals in a special thread
> 3. switch Emacs to an event loop model and handle all signals asynchronously

I'd start with the first half of (1).  It is not clear to me that the
other part is needed, and in any case we need a reproducer for it
first.  Most of the crashes we've seen until now were not when the MPS
handler was running.  Also, didn't someone say that when the MPS
SIGSEGV handler is active, we could detect that from our code and
return doing nothing?

> (1) is hard to do because we'd need to hijack the SIGSEGV handler and/or modify MPS
> (3) is a very major change which would mean permanently losing features we want
> (2) is very easy to do, but gets complicated for SIGPROF (which needs to be on the thread it's profiling) and emergency breakout signals which need to modify the main thread's state.
> 
> I've tried (2) and it fixes the specific reproducer I posted yesterday, as it should do in theory. I believe it's the most flexible approach which still gives us well-defined semantics for signal handlers. We'd need to add per-thread signals for the specific cases mentioned above. And, of course, its pthread-specific.

Doing (2) adds a whole lot of complexity to Emacs.  Most importantly,
we will be unable to access Lisp data safely, unwind-protect and the
entire specpdl stuff generally cannot be used, and signaling an error
would be fatal.  So I'd rather avoid that.