Re: igc, macOS avoiding signals

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

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

> 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

I've got something, using Eglot/clangd.

Executive summary: If a signal interrupts the Emacs thread, and we are
"inside MPS", meaning the Emacs threads owns an arena's mutex, the macOS
port thread can try to acquire the same mutex and won't get because the
Emacs thread that owns it is stopped by the signal.

It goes like this:

  ** mps_commit

  mps_commit
  -> mps_ap_trip
     -> ArenaEnter

  ** ArenaEnter

  ArenaEnter
  -> ArenaEnterLock non-recursive
    -> LockClaim arena lock
      -> pthread_mutex_lock.
    -> ShieldEnter
      -> shieldQueueReset
         Sets some members of a Shield, .inside = true

  ** MPS port thread

  protCatchThread
  -> mach_msg waiting
  -> protCatchOne thread involved has been stopped by OS
    -> ArenaAccess
      -> arenaClaimRingLock
         -> LockClaimGlobal
           -> LockClaim globalLock (static LockStruct)
      -> RING_FOR uninteresting macrology
      -> ArenaEnter for the 1 arena we have

  ** Global lock (uninteresting here)

  LockInitGlobal
  -> LockInit globalLock
  -> LockInit globalLockRecLock
     -> pthread_mutex_init with no interesting attrs

Sp, I'd say

- It's possible to freeze on macOS because of hitting a barrier, or
  allocating Lisp objects. I don't believe that I would have overlooked
  something preventing it.

- It's apparently very unlikely to happen, for me at least it
  never happened in, don't know, half a year or so of daily usage.
  Maybe one could make it happen when profiling for long enough.

- Only signal handlers are affected, and what you said about signal
  handlers using Lisp and so on.

Hm.