Re: igc, macOS avoiding signals

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  pipcet@protonmail.com,  spd@toadstyle.org,
>>   emacs-devel@gnu.org
>> Date: Tue, 31 Dec 2024 15:15:04 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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.
>
> If that really can happen, then pthreads is more fragile than I hoped.
> I hoped they don't let signals interrupt them when they are in
> critical sections like that.  Are we sure this danger is real?

I'm not a pthread expert. I don't know.

>> I'd like to instead revive the idea of getting the backtrace in the
>> signal handler and doing anything else elsewhere.
>
> If it works, sure.  But I thought copying the data had the same
> problems as accessing it from the handler?

Copying Lisp_Object around is not a problem, AFAIK (only saying that
because I'm getting cautious).

>> Maybe, after reading igc.org, that is acceptable maintenance-wise?
>
> Can you show a patch?

We haven't talked about what to do the sample after get_backtrace yet.
And I'm not sure if you accept the approach now or not, TBH. If that's
not the case, we can stop here and save time.