Re: Some experience with the igc branch

[Helmut Eller <eller.helmut@gmail.com>]

On Thu, Dec 26 2024, Eli Zaretskii wrote:

>> > Which means we should try talking to the MPS folks so that they
>> > provide us with the means of blocking some signals while the lock is
>> > held.  Like some callback MPS would call when it takes the lock and
>> > another one when it releases the lock.
>>
>> 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.

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.

> 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.  An advantage of blocking SIGPROF would be
that no #ifdefs HAVE_MPS would be needed.

Helmut