Re: scratch/igc: Implications of MPS being asynchronous

[Stefan Kangas]

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]

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

Footnotes:
[1]  
https://memory-pool-system.readthedocs.io/en/latest/glossary/a.html#term-asynchronous-garbage-collector