Re: igc, macOS avoiding signals

[Gerd Möllmann]

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

> 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?)

Thanks. I guess it shows that I couldn't keep up with my mail, sorry for
that.

So we have this picture, I think

              t1           t2                    t3
  ------------|------------|---------------------|-----------------> t
   signal        pthread      other stuff          signal handler
   handler       trylock      until return to      branching
   calling                    signal handler       on result of busy
   mps_arena_
   busy

We have a window [t1, t2] where the nested signals lead to undefined
behavior. and [t2, t3] where threads and nested signals can come into
play, but that's not a problem, iff signal handlers don't leave a lock
behind them.

Hm. Have you perhaps looked at a pthread implementation, what such a
mutex actually is on Linux?

>>
>> Now the question is if that's what Helmut was describing.
>
> Yes, that's what I meant.

Thanks.

> 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).  If the backtraces are the
> same, then we could record the backtrace there; that would be much
> nicer.

Yeah.