Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > 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's a rule, like "red light means stop".  Eli is saying that we can
>>> prove in certain circumstances that the rule isn't necessary, and then
>>> it's okay to ignore it.  I disagree.
>>
>> You are putting words into my mouth that I haven't said and didn't
>> mean to say.
>>
>> 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.  Because GC can be entered via a very small number of calls,
>> and it is not hard to define the conditions under which it can or
>> cannot be entered.
>>
>> 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.  So stating in a design document that this is impossible
>> is not useful, in addition to being false.
>
> Can an Emacs C module make (indirect or direct) use of the MPS
> functionality while running on another thread?

I don't know the answer.  I don't know whether there is an answer, at
this point: try it and see whether it works; if it doesn't, we'll ban
it, if it does, we can allow it.

> If the answer is affirmative, let's suppose that the Emacs C module
> running on another thread causes a call to some MPS gc function at some
> time. Does MPS interrupt the main Emacs thread to do the gc?

Yes.

I'm not sure whether the current MPS implementation ever stops all other
threads in response to one thread hitting a memory barrier, but that's a
technical question about an implementation detail: MPS certainly should
not be assumed not to do that.

Note that there are other problems with multi-threaded access to Lisp
memory: on WIDE_EMACS_INT builds or 8-bit machines, a Lisp_Object may be
half-written, and that's painful and horrible and we should never use
threads on such machines.  We should disable SIGPROF on them, too, as it
can crash or, worse, expelled^Wproduce unreliable data.

(I looked into using WIDE_EMACS_INT builds with scratch/igc, and posted
a patch to allow doing so.  However, I regret doing so.  The right thing
to do is to drop the WIDE_EMACS_INT build after making small bignums
behave like fixnums, which allows us to open 1.5 GB files in 32-bit
Emacs versions without the wastefulness and complications of
WIDE_EMACS_INT).

TBH, I'm not sure IGC's 64-bit headers are a good idea on 32-bit
machines.  I think they're *currently* safe, because we alter headers so
rarely, but I'd like to alter headers in more places, and that will have
to be done very carefully so half-written headers don't result in
crashes.

32-bit x86 allows atomic access to 8-byte words, but only via unusual
instructions.  I'm not sure ARM does (aarch64 uses atomic access to
16-byte words in ordinary code, which is very useful).

Pip