Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

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

> What I'm saying is that it's okay to have a rule like: "write your
> code as if GC could happen at any time".  But saying that GC actually
> _can_ happen at any time is too far-fetched since it's factually
> false.

No one said "can"!  The quote used "might", not even "may", and included
an extra "potentially", so you're objecting to a statement that no one
actually suggested.

Here's the statement, for reference:

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

Anyway, a separate background MPS collection thread isn't far-fetched,
and makes the hypothetical "GC actually can happen at any time"
statement true.

I'm not using one right now, but this discussion convinced me that we
should do so, and fix any and all bugs discovered that way, even if
there is a convoluted defense for why they may be impossible to trigger
without the extra thread.

> Because GC can be entered via a very small number of calls,

... and all accesses to memory behind a barrier ...

> and it is not hard to define the conditions under which it can or
> cannot be entered.

Please provide a definition, then.  I think it's very hard.

> And I do believe there will be practical cases (hopefully, very few
> and far in-between) where we will need to make such reasoning, because
> it's Emacs.

It's not clear to me what you're saying here: it's a design decision of
scratch/igc that we'll fix those "practical" cases in another way.
That's what we're doing now.

> So stating in a design document that this is impossible
> is not useful, in addition to being false.

How about:

> The MPS-based GC in scratch/igc does not allow or require application
> C code to make "no GC here" assumptions.

That's not false.  It's clearly a rule rather than a statement about
when GC actually happens.  It's a very useful rule.  It isn't stated as
elegantly as it is in the patch Stefan suggested, and leads to avoidable
confusion.

I prefer Stefan's wording, but if you insist on reading that as a
statement about when GC actually happens, rather than establishing a
rule, we'll have to go with the more convoluted statement I suggested
first.

Is your suggestion not to document this major design decision based on
your belief that we'll have to revisit and alter it at some point in the
future?  That doesn't make sense to me.

Or is your suggestion to alter the design decision now?

Pip