Re: igc, macOS avoiding signals

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  pipcet@protonmail.com,
>>   spd@toadstyle.org,  emacs-devel@gnu.org
>> Date: Tue, 31 Dec 2024 10:19:15 +0100
>> 
>> 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?)
>> 
>> 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.
>
> If the problem is other signals in [t1, t2], we could install the
> signal handler in a way that masks all other signals while the handler
> runs.

That would be necessary, but there's another thing Helmut pointed out.
At t0, when we enter the SIGPROF handler, we may have interrupted
pthread code in the Emacs thread, so pthread may currently be in an
inconsistent state.


I'd like to instead revive the idea of getting the backtrace in the
signal handler and doing anything else elsewhere. What I've seen so far
as alternatives is for my taste in the end too difficult.

We have established that calling get_backtrace is safe since it doesn't
access memory in our AMC pool, which might have a barrier. Counter
argument was that one would have to know too much about what is safe to
access and what cannot, and that would be unmaintainable.

What one has to know in get_backtrace is

- struct thread_state is safe because it is Lisp object. but it is not
  in the AMC pool, but another pool not using barriers. One could "hide"
  that knowledge by putting get_backtrace into igc.c. We only need the
  binding stack members (specpdl*) from current_thread. Another
  function.
  
- Accessing any other Lisp objects is taboo. That includes any memory of
  the object, in particular it includes their headers, i.e. type checks
  for PVEC types. One could require no type checks.
  
- Copying Lisp_Object and such is okay because that does not access
  the memory of the referenced object.

Maybe, after reading igc.org, that is acceptable maintenance-wise?