Re: igc, macOS avoiding signals

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Mon, Dec 30 2024, Gerd Möllmann wrote:
>>
>>> I'm afraid Modifying MPS is not my thing, But What about using something
>>> more modern like Oilpan (aka cppgc) from V8? Can be used as a lib, is
>>> concurrent for real.
>>
>> Ideally, Emacs would have an abstract GC interface so that different
>> implementations could be plugged in.
>
> That would indeed be nice to have.
>
>>> That would also be a perfect time to lift Emacs to
>>> C++.
>>
>> I'd rather see Emacs move to Rust.  Anyway, neither option seems
>> realistic.
>
> In mainline... (pondering to put a smiley).

I'll throw Zig in and run away quickly.

> But something else: Given what I now believe, I think I want to
> understand better (a bit) why everything appears to work just fine on
> macOS, with signals. Could you perhaps check if I'm off? MacOS only.

Do we know that?  I think macOS doesn't use signals as heavily as other
platforms do, and I don't know how SIGPROF is handled on that platform,
but I would not be surprised if that or SIGALRM require the signal
checking thing on macOS, too.

The macOS thing is equivalent to blocking signals in the SIGSEGV
handler.  I still think that's what MPS should have done.

> In normal operation, there are only ever 2 threads running. An Emacs
> thread is interrupted by a signal and lands in a signal handler, the
> MPS port thread keeps running.
>
> In the signal handler, hitting barriers is handled by the MPS port
> thread. Consistency of Emacs's state is a problem the signal handler has
> to deal with, consistency of MPS' GC data is a problem that hopefully
> MPS handles, and it seems to work.
>
> I think I understand that, except when the Emacs thread is interrupted
> while in MPS code, which happens for allocation points running out of
> memory and mps_arena_step (idle time).

My assumption is that if the signal handler is allowed to run in that
case, and tries to access MPS-managed memory, we deadlock.  It might not
be a detectable deadlock causing a crash, as it would be on POSIX, but
that makes things worse, not better.

Pip