Re: MPS: a random backtrace while toying with gdb

[Pip Cet <pipcet@protonmail.com>]

On Tuesday, July 2nd, 2024 at 17:06, Pip Cet <pipcet@protonmail.com> wrote:
> > But even if I'm wrong, why is that important? We need to solve both
> > kinds of situations, don't we?
> 
> Now that we have a way to reproducibly make it happen, yes, I agree.

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

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

Pip