Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 22 Dec 2024 22:26:11 +0000
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org,
>  Helmut Eller <eller.helmut@gmail.com>, Andrea Corallo <acorallo@gnu.org>
> From:  Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> >> 1. The signal issue.  I don't have a good way to fix this and make
> >> everyone happy, but I do have a solution which hasn't caused a crash for
> >> me in quite a while.  It may be good enough.
> >
> > TBH, I'd have put it in already.
> 
> Pushed it now.  It is imperfect, but better than crashing.

Why didn't we discuss this with MPS folks?  A program can legitimately
call some code from a signal handler, so the limitations that MPS
seems to impose now are not very reasonable.  Maybe we are missing
some feature, or maybe the MPS folks will agree to extend the library
to provide better support for programs that use signals.  E.g., AFAIU
with this code installed, we are limiting our profiler too much (it
will never report GC, IIRC?).  I think igc_busy_p returns non-zero in
too many situations where delivering signals could not possibly cause
harm, like during object allocation, AFAIR.  According to
documentation, that function is not intended for this kind of purpose.

IOW, we had discussions about this which never concluded anything, and
we should pick up where we left off and solve this problem.

We should definitely try improving this before we land the branch on
master.  We shouldn't consider this solution "good enough", but just a
temporary kludge meant to avoid too frequent crashes.