Re: Some experience with the igc branch

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  pipcet@protonmail.com,  ofv@wanadoo.es,
>   emacs-devel@gnu.org,  acorallo@gnu.org
> Date: Thu, 26 Dec 2024 09:02:11 +0100
> 
> On Thu, Dec 26 2024, Eli Zaretskii wrote:
> 
> >> Your position is that blocking SIGPROF while MPS holds the lock is
> >> the correct thing to do, right?
> >
> > Yes, I think so.  (If you disagree, please tell why, and let's discuss
> > that.)  It is certainly a relatively simple thing to do.
> 
> I quite like Pip's proposal of re-installing the SIGSEGV handler with an
> additional sa_mask argument to block other signals.  That would be nice
> because a) we can do that without changing MPS and b) it's likely more
> efficient than callbacks.

Are we sure doing so will solve the problem?  AFAIU, MPS can take the
lock before SIGSEGV is delivered, or without its being delivered at
all, isn't that so?

(Besides, the sa_mask way won't work on Windows, which doesn't have
sigaction and its emulation currently ignores sa_mask; we'd need to
extend the emulation, but that will still leave a small window where
the other signals are not immediately blocked after SIGSEGV.)

> It would still be nice to simplify some signal handlers, like
> handle_interrupt_signal, but with other signals blocked for SIGSEGV, it
> would all be quite independent of MPS.

Maybe.  What bothers me more is whether the signals are delivered only
to the main thread or to other threads.  AFAIU, this behavior is
system-dependent, and currently we seem to rely on the fact that the
signals is delivered to the main thread.  Given that we have other
threads, including the MPS thread, I'm not sure we have this figured
out.

> > It is also possible for MPS to somehow manage an attempt to take the
> > lock which is already held in a smarter way, by stopping the code
> > which does that until MPS releases the lock.  For example, MPS could
> > define a protocol for such situations not unlike the GIL protocol we
> > use for Lisp threads.  But that's much more complex, and I don't
> > necessarily expect the MPS folks to go to such lengths.
> 
> I think that mps_arena_busy, which tests whether MPS holds the lock, is
> quite adequate for the SIGPROF handler. It lets us detect the situation
> and increment some counter.

I'd like to have MPS folks confirm that.  The documentation of this
function seems to say we shouldn't use it "normally", only for
debugging (so perhaps in some commands in .gdbinit).  And see also
this warning in their docs:

          Warning: This function only gives a reliable result in
          single-threaded programs, and in multi-threaded programs where
          all threads but one are known to be stopped (as they are when
          the debugger is decoding the call stack in the use case
          described above).

AFAIU, Emacs doesn't fulfill the condition they define.

Also, the code we currently have on the branch doesn't just "increment
some counter", it flatly blocks the signal.

For these reasons, I'm not happy with our current usage of that
function for this purpose.