[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: igc, macOS avoiding signals
From: |
Pip Cet |
Subject: |
Re: igc, macOS avoiding signals |
Date: |
Mon, 30 Dec 2024 11:18:16 +0000 |
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
- Re: igc, macOS avoiding signals, (continued)
- Re: igc, macOS avoiding signals, Eli Zaretskii, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Eli Zaretskii, 2024/12/30
- Re: igc, macOS avoiding signals, Helmut Eller, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
- Re: igc, macOS avoiding signals,
Pip Cet <=
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Pip Cet, 2024/12/30
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2024/12/30
Re: igc, macOS avoiding signals, Pip Cet, 2024/12/28