Re: Some experience with the igc branch

[Eli Zaretskii]

> Date: Fri, 27 Dec 2024 17:26:04 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, stefankangas@gmail.com, 
> ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >   - Concurrent.  The GC runs in its own thread.  There are no explicit
> >     calls to start GC, and Emacs doesn't have to wait for the GC to
> >     complete.
> >
> > Pip says this is not true?
> 
> I'm a bit confused.  Right now, on scratch/igc, on GNU/Linux, for Emacs
> in batch mode, it isn't technically true.  This causes the signal
> handler issue, which we're trying to solve.

The signal handler issue is because igc can happen on our main thread
as well.  IOW, there are two possible triggers for igc, and one of
them is concurrent.

> > I also thought MPS GC runs concurrently in its own thread.
> 
> That's what you should think: GC can strike at any time.

The same is true with the old GC.

> If your code assumes it can't, it's broken.

I disagree.  Sometimes you need to do stuff that cannot allow GC, and
that's okay if we have means to prevent GC when we need that.

> As far as everybody but igc.c is concerned, it's safer to assume that GC
> runs on a separate thread.

We are not talking about assumptions here, we are talking about facts.
If igc is concurrent, it means it runs on a separate thread.  If it
doesn't run on a separate thread, it's not concurrent.  We need to
establish which is the truth, so we understand what we are dealing
with.  Assumptions about our application code come later.