Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

"Stefan Kangas" <stefankangas@gmail.com> writes:

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

Yes, but I think this is a minor detail that does not need to be in the
docs:

In the HAVE_MPS build, SDATA pointers in automatic variables keep their
string data alive and in place.  In the !HAVE_MPS build, they don't, so
we can never GC between calling SDATA and the last use of that pointer.

One minor point is that this no-GC assumption is usually not enforced by
calling inhibit_gc.  If we're lucky, there's a comment somewhere, but
usually not in the place where the assumption is made.

However, "not allow or require" is redundant: of course it's not
required to do impossible things!  "The law never requires
impossibilities", as the California Civil Code says.

> I would suggest documenting this somehow.  The attached patch is the
> best proposal I could come up with based on my understanding so far.
> Does what I wrote there make sense?  Should it be expanded somehow?

That looks great, thanks!

Pip