Re: igc, macOS avoiding signals

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

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

I don't think that's a problem.  Here's why:

We'd have to call the POSIX police.  I believe it's a conscious POSIX
decision not to allow hand-over of locks from one thread/signal handler
(those can't even call _trylock) to another; this is relevant to the
priority inversion scenario (if we had a "background" GC thread running
at a lower priority (whatever that would mean?  E-core?  Different
power-performance prefs?  Throttled?), the main thread would have to
find a way to boost its priority (move it to a P-core, unthrottle,
whatever) if we're actually waiting for it to release the arena lock.
One way would be to take over its lock (easy) and stack (hard) while
retaining thread settings, but POSIX decided we don't want to do that.
Thank you, POSIX (in this case)).

On inhomogeneous systems (almost everything you can buy today, ESP32 to
server CPU), "priority inversion" can happen with just two threads,
since priority is no longer defined by access to a single or several
identical cores.

But anyway, POSIX prohibits it, glibc on GNU/Linux doesn't support it,
I'm not aware of any other systems making that useful, certainly not for
Emacs.

> That would be a very unusual signal handler.  I hope no other surprises happen in signal handlers.

longjmp-based green threads?  (MPS currently assumes a simple linear
stack, gcc can produce split-stack code, getting that combination to
work would be good; I can dig up the patch for enabling it for the old
GC).

Pip