Re: MPS: profiler

[Eli Zaretskii]

> Date: Fri, 21 Jun 2024 11:00:02 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: yantar92@posteo.net, emacs-devel@gnu.org, gerd.moellmann@gmail.com, 
> eller.helmut@gmail.com
> 
> > > The right thing to do, IMHO, is to let MPS know that it should block 
> > > SIGPROF (and any other signals that might use managed memory) while 
> > > handling SIGSEGV.
> > 
> > I disagree. MPS must be able to support programs compiled with
> > "-gprof", so I don't believe SIGPROF should be blocked.
> 
> Only while handling SIGSEGV, of course.
> 
> > The handler
> > is our code, so we should modify the handler not to do anything unsafe
> > if SIGPROF happens while MPS is processing its SIGSEGV. That's a much
> > more reliable fix, and one that will allow us to keep our profiling
> > code.
> 
> Why are you suggesting that my "fix" (which, yes, is overly broad, we'd need 
> to go through the signals to find all we can safely leave unblocked) requires 
> any changes to the profiling code? As far as I can tell, it just works.
> 
> The main difference between the two approaches, both of which require 
> meddling with MPS internals, is that if SIGPROF is blocked, it will be 
> delivered with a delay after the SIGSEGV handler is done running. If the 
> SIGPROF handler runs and doesn't do "anything unsafe", on the other hand, it 
> can record the unusable signal but won't get a new one. I don't see a clear 
> advantage of either, to be honest. Blocking signals, of course, is more 
> reliable than "just knowing" we won't do anything unsafe.

I simply don't believe MPS is so poorly designed as to disallow
signals while its own SIGSEGV handler runs.  SIGPROF is just one
example; there are also SIGALRM, SIGUSR1, SIGUSR2, and maybe others.
It makes little sense to me to expect MPS to block these signals.  I
rather expect them to DTRT with those signals.

My first suspect is our own code.  Until we establish positively that
our code is fine, and what happens here is that we hit the MPS
protection in our SIGPROF handler, I don't think we should consider
changes in the MPS code.