Re: igc, macOS avoiding signals

[Gerd Möllmann]

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

> On Mon, Dec 30 2024, Gerd Möllmann wrote:
>
>> Bool (LockIsHeld)(Lock lock)
>> {
>>   AVERT(Lock, lock);
>>   if (pthread_mutex_trylock(&lock->mut) == 0) {
>>     Bool claimed = lock->claims > 0;
>>     int res = pthread_mutex_unlock(&lock->mut);
>>     AVER(res == 0);
>>     return claimed;
>>   }
>>   return TRUE;
>> }
>>
>> There might be a small window after pthread_mutex_trylock and being back
>> in the signal handler. Can anything happen in this window?
>>
>> If no other Emacs threads are running, and the Emacs thread is in the
>> signal handler, we can trust the "false" from the mps_arena_busy.
>
> Theoretically, a signal handler could interrupt the Emacs thread and
> lock the mutex without unlocking it.  That would be a very unusual
> signal handler.  I hope no other surprises happen in signal handlers.
>
> Helmut

Right, that one I forgot. A nested signal may interrupt the signal
handler and acquire the lock in its signal handler but not release it.
The effect would be that the original signal handler would see a false
from mps_arena_busy which would not the truth.

I'd call that a bug in the nested signal handler.