[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some experience with the igc branch
From: |
Eli Zaretskii |
Subject: |
Re: Some experience with the igc branch |
Date: |
Thu, 26 Dec 2024 17:23:43 +0200 |
> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es,
> emacs-devel@gnu.org, acorallo@gnu.org
> Date: Thu, 26 Dec 2024 13:24:13 +0100
>
> On Thu, Dec 26 2024, Eli Zaretskii wrote:
>
> >> I quite like Pip's proposal of re-installing the SIGSEGV handler with an
> >> additional sa_mask argument to block other signals. That would be nice
> >> because a) we can do that without changing MPS and b) it's likely more
> >> efficient than callbacks.
> >
> > Are we sure doing so will solve the problem? AFAIU, MPS can take the
> > lock before SIGSEGV is delivered, or without its being delivered at
> > all, isn't that so?
>
> Ahem. I completely forgot that.
>
> An alternative to callbacks would be to implement our own lock module as
> described here:
>
> https://memory-pool-system.readthedocs.io/en/latest/topic/porting.html
>
> It would probably be a clean and efficient solution; but it would
> basically be our own fork of MPS.
Probably. I still think we should talk to the MPS folks and hear what
they suggest.
> >> It would still be nice to simplify some signal handlers, like
> >> handle_interrupt_signal, but with other signals blocked for SIGSEGV, it
> >> would all be quite independent of MPS.
> >
> > Maybe. What bothers me more is whether the signals are delivered only
> > to the main thread or to other threads. AFAIU, this behavior is
> > system-dependent, and currently we seem to rely on the fact that the
> > signals is delivered to the main thread. Given that we have other
> > threads, including the MPS thread, I'm not sure we have this figured
> > out.
>
> I thought deliver_process_signal was there to forward signals to the
> main thread but you certainly know better what it does and doesn't.
Actually, we need Paul Eggert to chime in, because he knows much more
about this than I do. We have arrangements for when a signal is
delivered to a thread, but I think Paul said this should rarely if
ever happen. My bother is what if the signal is delivered when the
MPS thread runs.
- Re: Some experience with the igc branch, (continued)
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/25
- Re: Some experience with the igc branch, Gerd Möllmann, 2024/12/25
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/25
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/25
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/26
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/26
- Re: Some experience with the igc branch, Helmut Eller, 2024/12/26
- Re: Some experience with the igc branch,
Eli Zaretskii <=
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/26
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/27
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/27
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/28
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/28
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29
- Re: Some experience with the igc branch, Paul Eggert, 2024/12/29
- Re: Some experience with the igc branch, Eli Zaretskii, 2024/12/29