Re: igc, macOS avoiding signals

[Gerd Möllmann]

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

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.

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

Do you agree so far? If yes, I'd bite the bullet and look at the MPS
code for macOS how that is done, if it's done.