Re: igc, macOS avoiding signals

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

On Mon, Dec 30 2024, Gerd Möllmann wrote:

[...]
> But something else: Given what I now believe, I think I want to
> understand better (a bit) why everything appears to work just fine on
> macOS, with signals. Could you perhaps check if I'm off? MacOS only.
>
> In normal operation, there are only ever 2 threads running. An Emacs
> thread is interrupted by a signal and lands in a signal handler, the
> MPS port thread keeps running.
>
> In the signal handler, hitting barriers is handled by the MPS port
> thread. Consistency of Emacs's state is a problem the signal handler has
> to deal with,

Agreed.

> consistency of MPS' GC data is a problem that hopefully
> MPS handles, and it seems to work.

My interpretation of this design document[*], is that MPS's arena lock
protects most of MPS entry points.  There are a few (e.g. mps_reserve
and mp_ld_add) that don't claim the arena lock and for those it's the
burden of the client to call them in a thread safe way.  For us this
probably means: don't call them in a signal handler.

The main entry point that we want to call in the signal handler is the
SEGFAULT handler (not sure how this works on MacOS).  The fault handler
claims the non-recursive arena lock.  So, in the signal handler we
should not hold the lock while hitting a barrier.

> I think I understand that, except when the Emacs thread is interrupted
> while in MPS code, which happens for allocation points running out of
> memory and mps_arena_step (idle time).

Hmm, is that sentence incomplete?  I don't quite understand it.

> Do you agree so far? If yes, I'd bite the bullet and look at the MPS
> code for macOS how that is done, if it's done.

Yes, mostly.

Helmut