Re: igc, macOS avoiding signals

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

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

> 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 PTHREAD_MUTEX_ERRORCHECK_NP case looks fine to me, assuming signal
handlers balance successful trylock calls with unlocks in the same
handler.  It uses __data.__lock to serialize access to the plain old C
data in the mutex struct, and doesn't touch anything if it can't acquire
the lock atomically (that's what lll does).

PTHREAD_MUTEX_RECURSIVE_NP, not so much, so don't use recursive mutexes
:-)

> The struct may simply be in an inconsistent state at the time t0, the
> beginning of the SIGPROF handler.

It could certainly be made to fail more loudly in the case of acquiring
a recursive mutex from a signal handler.  Someone might try to do that
to build a non-recursive mutex based on recursive mutexes, but that's
the only use case I can see.

Alternatively, let's all switch to FreeDOS!  No memory barriers, no
signals, pdumper works now, and MPS just survived its first GC cycle.

I said I wasn't going to port MPS to DOS, but I didn't have to; the
ANSI C environment works fine, eagerly tripping all memory barriers
rather than installing them.

The real point of that experiment was to test whether the ANSI C
environment might be a useful fire exit in case there are unfixable
protection problems on some platforms.

(It's true that most DOS "extenders" appear to use the MMU, and that
might make it sound like mprotect() could simply involve walking the
(unprotected) page tables; but my understanding is it's 4MB pages, which
is inconvenient for us).

Pip