Re: igc, macOS avoiding signals

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

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

>> 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.
>
> Okay, that I think I understand then. The "only" difference between
> macOS and Linux is that on macOS no SEGV handler is involved. Hitting
> the barrier on macOS means that the EXC_BAD_ACCESS port thread, which
> was waiting for Mach message, receives a message from the OS and starts
> working.

I guess that both, macOS and Linux version, will end up in ArenaAccess.
Perhaps on macOS in the other thread.

>>> 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.
>
> What I meant is that I imagine a signal interrupts the Emacs thread at a
> point where we are "in MPS". AreaEnter/Leave I think I understand, it's
> some pthread_mutex_t, I think, from other mails. A problematic "in MPS"
> could then be "while the Emacs thread owns the mutex". The places where
> I imagine that mutex could be owned are mps_arena_step (I call it Emacs
> is idle) and mps_commit (in alloc_impl, when the allocation point used
> runs out of memory). Maybe other places, but mainly these two.

Yes.

> And the question on macOS for me would be if the port thread tries to
> qcquire the same mutex, or how the heck that works. Or IOW, if there is
> a problem, why I've never seen it happening in all that time I'm using
> igc.

Maybe you could set a breakpoint in AreaAccess to find out which thread
removes the barriers.

> I find that difficult to understand. But it may be just a
> statistical phenomenon. Maybe filling up an APs memory is so fast so
> that the probability of a signal hitting while owning the mutex is close
> to zero, or something. 

Very few of Emacs' signal handlers actually touch a barrier.  I've also
not seen any reproducable receipes for the "signal issues" that the igc
branch supposedly has.

Helmut