Re: Some experience with the igc branch

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> 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

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.

Pip