Re: igc, macOS avoiding signals

[Helmut Eller <eller.helmut@gmail.com>]

On Tue, Dec 31 2024, Gerd Möllmann wrote:

> Helmut Eller <eller.helmut@gmail.com> writes:
[...]
>> 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?)
[...]
> 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?

Judging from the source here

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/nptl/bits/struct_mutex.h;hb=HEAD

and here

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/pthread_mutex_trylock.c;hb=HEAD

I would say that the mutex is a struct with multiple fields and that
pthread_mutex_trylock is neither a syscall nor an atomic instruction.
The struct may simply be in an inconsistent state at the time t0, the
beginning of the SIGPROF handler.

Helmut