Re: igc, macOS avoiding signals

[Helmut Eller]

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

>> That the SIGPROF handler in the form he described would be safe?  I
>> agree.
>
> What we have in scratch/igc:
[...]
> static void
> add_sample (struct profiler_log *plog, EMACS_INT count)
> {
> #ifdef HAVE_MPS
>   if (igc_busy_p ())
> #else
>   if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */
> #endif
>     /* Special case the time-count inside GC because the hash-table
>        code is not prepared to be used while the GC is running.
>        More specifically it uses ASIZE at many places where it does
>        not expect the ARRAY_MARK_FLAG to be set.  We could try and
>        harden the hash-table code, but it doesn't seem worth the
>        effort.  */
>     plog->gc_count = saturated_add (plog->gc_count, count);
>   else
>     record_backtrace (plog, count);
> }
[...]
>
> Now the question is if that's what Helmut was describing.

Yes, that's what I meant.

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.

Helmut