Re: Some experience with the igc branch

[Eli Zaretskii]

> Date: Sat, 28 Dec 2024 12:35:09 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: 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:
> 
> >> 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
> 
> Yes.
> 
> > as well.
> 
> It always happens on the main thread if that's all we've got.  Even
> macOS emulated SIGSEGV suspends the main thread while the message is
> being handled, then resumes it afterwards.
> 
> > IOW, there are two possible triggers for igc,
> 
> Three, if you count the idle work.
> 
> > and one of them is concurrent.
> 
> I'd prefer to avoid that word.  There are facts we need to establish,
> and "concurrent" isn't well-defined enough to be helpful here.
> 
> On single-threaded batch-mode GNU/Linux Emacs, on scratch/igc, no second
> thread is created for MPS.  My understanding is this is a useful,
> common, and intentional scenario for running MPS, not a bug or an
> accident.
> 
> Of course we're free to change that, and run MPS from another thread,
> but that's not a no-brainer.
> 
> >> > 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.
> 
> The old GC emphatically could not "strike at any time".  There is plenty
> of code that assumes it doesn't strike.  Some of it might even be
> correct.
> 
> >> 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.
> 
> So now you're saying it's okay for code to assume GC can't strike, after
> agreeing a few lines up that it's not okay for code to do so.  Which one
> is it?
> 
> >> 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.
> 
> The fact is we don't even know whether GC is usually on a "separate"
> thread on macOS and Windows.  On GNU/Linux, assuming it does leads to
> bugs.
> 
> > 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.
> 
> Those two statements are equivalent.  They're not sufficient to define
> "concurrent"-as-Eli-understands-it, just for establishing a necessary
> condition for that.
> 
> If we agree on that condition, then no, MPS is not always
> concurrent-as-Eli-understands-it.
> 
> > We need to establish which is the truth, so we understand what we are
> > dealing with.
> 
> Why?  Whatever the truth is, we can safely assume it's an implementation
> detail and not rely on it.
> 
> We don't need to agree on a definition of concurrency.
> 
> We don't need to agree on what's likely, just that single-thread
> operation of MPS and parallel MPS threads are both possible and not
> bugs.

You respond as if what I wrote had as its purpose to attack or offend
you.  It wasn't; all I want is to establish the truth.  Please read
what I write with that in mind, and drop the attitude, because it
doesn't help.