Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii]

> Date: Sun, 30 Jun 2024 10:16:42 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org, 
> eller.helmut@gmail.com
> 
> > > We could always "steal" the SIGSEGV handler and reinstall it with a 
> > > sigmask (without modifying the MPS source). My guess is that's equivalent 
> > > to what the macOS code does, essentially, by using a different class of 
> > > signal that blocks POSIX signals...
> > 
> > 
> > And this is less "ugly" (let alone more safe) than using sigblock?
> > What am I missing?
> 
> Mostly, I think, the race condition where the barrier is installed (by MPS) 
> some time before dflt_scan is even called (and, symmetrically, we'd unblock 
> it too early while the barrier is still in effect). IOW, sigblock wouldn't 
> work.

Then we should block signals earlier, e.g., in igc_alloc (and any
other place which could cause our objects moved).

> (I should point out that you've convinced me as far as SIGPROF goes. At least 
> for the initial stage, it makes more sense to count hits in GC (which we do, 
> with false positives, using the current scratch/igc code) than to delay 
> signal processing until GC is over).

SIGPROF is not the only one.  We have other useful signals, and we
need to think about a solution that will cover most if not all of
them.  I've listed the signals that came to mind a few messages ago.

I still cannot believe MPS doesn't have a canonical solution for these
cases.