Re: Not protecting Lisp objects from GC

[Pip Cet]

"Stefan Kangas" <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> If someone suggests a simpler, cleaner change, I might reconsider.
>
> We are now in a situation where the feature/igc developers are
> protesting vehemently against this, to the extent that there is even
> talk of not merging feature/igc at all.  This is not a good outcome.
>
> One side in this discussion argue that removing DEFVAR_LISP_NOPRO is
> risk-free, or something close to it, and decreases the risk for GC bugs.
>
> The other side argues that any change comes with inherent risk,
> especially in a currently poorly understood area like font.c, and that
> keeping what we have is low risk.
>
> Since this discussion seems to revolve around managing risk in different
> ways, I would suggest the following compromise:
>
> 1. We install the attached patch on master _as an experiment_, which
>    means that we install it with the understanding that we are keeping
>    the option open to revert it later.  We have used this method in the
>    past to good effect.
>
> 2. We agree to re-evaluate the patch before the fist pretest for Emacs
>    31.1, or even sooner, keeping the option open to revert it if needed.
>
> 3. If there is no trouble with the patch, we leave it as is.  The
>    pretest will give us more opportunities to get this change tested in
>    various configurations.
>
> 4. We keep the option open to revert it at any point during the pretest
>    also, if it turns out to be causing issues.
>
> I hope that this could make everyone happy, and let us get back to our
> regularly scheduled hacking.
>
> Can everyone please let me know what they think?

About the patch:

I proposed these two patches as a minimal fix:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#19
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75521#88

The main difference in your patch is that defvar_lisp_nopro is kept and
remains exported, making your patch even more minimal.  This would make
it easier to restore the old behavior if "git revert" fails due to some
unrelated change, so I agree with this change.

The other difference is what's in the .c file comments in lread.c and
alloc.c.  The minor issue of preexisting outdated comments should not
stop us here.

As for the compromise proposal:

I've read this as a memorandum of understanding, not a binding contract
or a promise.  If that is correct, it sounds good to me.

IIUC, the compromise is meant to apply to this one specific problem
only.  This would be a good thing.  Let me know if I'm not UC.

This response is about the compromise proposal only.

Pip