Re: igc, macOS avoiding signals

[Pip Cet]

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

> On Mon, Dec 30 2024, Pip Cet wrote:
>
>> "Helmut Eller" <eller.helmut@gmail.com> writes:
>>> Very few of Emacs' signal handlers actually touch a barrier.  I've also
>>
>> Indeed.  These crashes are rare in typical usage, which doesn't mean we
>> should delay fixing them until Emacs is "unstable enough".  It already
>> is, IMHO, because we take that approach too frequently.
>>
>>> not seen any reproducable receipes for the "signal issues" that the igc
>>> branch supposedly has.
>>
>> Removing the SIGPROF protection code should allow Ihor's recipe to crash
>> again.
>
> Talking about SIGPROF protection code.  It appears to me now (again)
> that, for the SIGPROF handler, this pseudo code
>
>   if (mps_arena_busy (<arena>))
>     plog->gc_count = saturated_add (plog->gc_count, count);
>   else
>     record_backtrace (plog, count);
>
> is safe.

Yes, it's safe, because it does have protection code.  The question was
the extent to which this protection code is required, and whether we can
find another way to deliver signals which doesn't require it.

IMHO, we now have three solutions that are still in the running (my
order of preference):

1. keep the current code and special-case some signals which are needed
for user responsiveness
2. use the signal serialization thread you proposed
3. use an allocation thread, but keep SIGSEGV on the main thread

The first two can be combined with blocking other signals in the SIGSEGV
handler (which would make all platforms behave the same and avoid
SIGSEGV-handler-SIGSEGV races).  The third requires it.

I'd like to take (3) out of the picture for now.  It's working here
(still forwarding SIGSEGV, but that's not the point), and performance
seems okay (better, for some unknown reason; maybe it's just chunk
size), but I couldn't make it behave reproducibly when run under rr, and
it makes a "GC is rare" assumption when it splits MPS objects.  I'd like
to be able to use rr, and "rare GC" assumptions mean that further
improvements to or even fine-tuning of MPS would have to happen
differently.

IOW, MPS needs hacking to make an allocation thread truly viable, mostly
to distinguish fast-path and slow-path allocations.  Not a major change,
I hope, but also out of scope for getting things to work with upstream
MPS, which remains my goal.

I think improving (1) is most likely to do that (but that would require
a shadow signal mask, most likely).

> If we don't hold the lock, then mps_arena_busy returns false
> and we can access memory.  We are safe even if another thread has
> claimed the lock by the time that we reach record_backtrace: the SIGPROF
> handler will just block until the lock is released.
>
> Does somebody disagree?

Not me.

Pip