Re: Some experience with the igc branch

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

On Thu, Dec 26 2024, Eli Zaretskii wrote:

>> > 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?

Ahem.  I completely forgot that.

An alternative to callbacks would be to implement our own lock module as
described here:

 https://memory-pool-system.readthedocs.io/en/latest/topic/porting.html

It would probably be a clean and efficient solution; but it would
basically be our own fork of MPS.

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

I thought deliver_process_signal was there to forward signals to the
main thread but you certainly know better what it does and doesn't.

Helmut