emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: igc, macOS avoiding signals


From: Eli Zaretskii
Subject: Re: igc, macOS avoiding signals
Date: Mon, 30 Dec 2024 19:49:26 +0200

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Pip Cet <pipcet@protonmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   spd@toadstyle.org,  emacs-devel@gnu.org
> Date: Mon, 30 Dec 2024 17:57:02 +0100
> 
> 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.

We should keep our signal handlers very simple and safe, that's true.
It is not very hard, and much of that work was already done, when we
stopped running complex stuff in SIGIO handler etc.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]