Re: igc, macOS avoiding signals

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

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?  

It's not correct, sorry. When it lands in the port thread, the Emacs
thread has been suspended by the OS.

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

That's right. The port thread can't get the lock because it's owned by
the Emacs thread. And the Emacs thread is suspended by the OS.

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

The Emacs thread is suspended by the OS to let the port thread handle the
situation. After the thread is suspended, the OS sends the port a
message. The port thread is waiting for such a message with mach_msg.
The port does its thing, and when it replies to the OS message
accordingly, the OS lets the Emacs thread continue. But that reply is
never sent because the port is stuck on the mutex.

Hope that's more correct.