Re: scratch/igc: Implications of MPS being asynchronous

[Eli Zaretskii]

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

> > And saying that "no GC here" assumptions are always false is too
> > radical to my palate, and AFAIU is at least not accurate.
> 
> I'm not sure what "radical" means in this context.  If it is true, we
> should write it, and if not, we shouldn't.

It is not accurate, which means it is not universally true.