Re: scratch/igc: Implications of MPS being asynchronous

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 12 Jan 2025 03:53:49 -0800
> Cc: emacs-devel@gnu.org, pipcet@protonmail.com, gerd@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> Date: Sun, 12 Jan 2025 11:19:21 +0000
> >> Cc: emacs-devel@gnu.org, pipcet@protonmail.com, gerd@gnu.org
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> >> Date: Sun, 12 Jan 2025 10:17:30 +0000
> >> >> Cc: pipcet@protonmail.com, gerd@gnu.org
> >> >>
> >> >> In Bug#75322, Pip Cet writes:
> >> >>
> >> >> > The MPS-based GC in scratch/igc does not allow or require application
> >> >> > C code to make "no GC here" assumptions.
> >> >>
> >> >> This is stated quite unambiguously also in the MPS guide:
> >> >>
> >> >>      "The MPS is asynchronous: this means that it might be scanning,
> >> >>      moving, or collecting, at any point in time (potentially, between
> >> >>      any pair of instructions in your program)."  (Chapter 2)
> >> >>
> >> >> This makes it clear what it means not to "allow" C code to make "no GC
> >> >> here" assumptions.  But I don't understand what it means that it is not
> >> >> "required" to make such assumptions.  Could someone clarify that part
> >> >> please?
> >> >
> >> > The above text is misleading: "asynchronous" doesn't seem to be
> >> > relevant to the part of MPS we are using, since its GC runs on our
> >> > threads, not on a separate thread.
> >>
> >> My understanding is that this applies also when we run MPS on the same
> >> thread.  Is that wrong?
> >
> > Yes.  Anything that runs from our application threads, and must
> > complete before our application thread can continue, cannot by
> > definition be "asynchronous".
> 
> The definition of "asynchronous" in the MPS sense is this:
> 
>     "A collector (2) is asynchronous with respect to the mutator if it
>     cannot be (easily) predicted when the collector will run."[1]

This is a strange definition.  It means that the current
(a.k.a. "old") GC in Emacs is also "asynchronous".

It is not a good definition because it tricks people to think MPS runs
on a separate thread.  Which it doesn't, at least not with the current
code on the igc branch.

This problematic definition already caused Gerd to think MPS runs on
separate threads.  Why risking the same fundamental misunderstanding
by others?

> Do you have a better word to propose here than "asynchronous"?

I don't think this aspect of MPS is very important to us.  So I would
suggest simply dropping that part.