Re: igc, macOS avoiding signals

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  spd@toadstyle.org,
>>   pipcet@protonmail.com,  emacs-devel@gnu.org
>> Date: Mon, 30 Dec 2024 12:53:33 +0100
>>
>> 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.
>
> Are you sure the "because the Emacs thread that owns it is stopped by
> the signal" part is correct?  AFAIU, since the macOS port thread is a
> different thread, it tries to take the arena lock, and is simply stuck
> there, waiting for the main thread to release the lock.  IOW, this is
> a simple mutex-based synchronization between two threads, that's all:
> one thread takes the lock, the other must wait until the first one
> releases it before it itself can take the lock.

My understanding is that the main thread cannot continue running while
it's waiting for a memory barrier to be removed.  What would it use for
the memory values it cannot access?

> Moreover, the main thread is not stopped, it runs the signal handler.

It is stopped, in the signal handler, waiting for the memory barrier to
be removed.

Pip