Re: igc, macOS avoiding signals

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Helmut Eller <eller.helmut@gmail.com> writes:

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

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

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

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

Thanks for your help! I'll post something when I think I have something.