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: Tue, 31 Dec 2024 15:14:39 +0200

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  pipcet@protonmail.com,
>   spd@toadstyle.org,  emacs-devel@gnu.org
> Date: Tue, 31 Dec 2024 08:34:42 +0100
> 
> On Mon, Dec 30 2024, Gerd Möllmann wrote:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >>> Cc: Helmut Eller <eller.helmut@gmail.com>,  pipcet@protonmail.com,
> >>>   spd@toadstyle.org,  emacs-devel@gnu.org
> >>> Date: Mon, 30 Dec 2024 19:37:38 +0100
> >>> 
> >>> So, to summarize, everyone agrees with Helmut?
> 
> Except the POSIX police: it says that pthread_mutex_trylock isn't async
> signal safe.  I suppose this also makes it's unsafe to use MPS's fault
> handler in an async signal handler.  Bummer.  (Does the police take
> bribes?)

Doesn't MPS itself call it from a SIGSEGV handler?

> I wonder if the backtrace that we see in the signal handler is any
> different from the backrace that we would see at the next safe point
> (i.e. the next time maybe_quit is called).

I think we cannot rely on that, because maybe_quit must be called by
hand, it isn't magic.  We call it from various places in the
interpreter, which could well be in some other place of a Lisp
program.

Once again, why not ask the MPS folks to give us a callback?  Or maybe
we could try hacking MPS ourselves first, to see if that does the job,
and ask them then?



reply via email to

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