Re: scratch/igc: Implications of MPS being asynchronous

[Pip Cet]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Can an Emacs C module make (indirect or direct) use of the MPS
>>> functionality while running on another thread?
>>
>> Emacs modules are not supposed to manipulate Lisp objects on another
>> thread, because doing that will cause trouble, given the global state
>> of Emacs.
>>
>>> 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?
>>
>> If you trigger MPS by modifying Lisp objects, or data structures that
>> include references to Lisp objects, from a non-Lisp thread, you are
>> asking for trouble.  Just think about it: the Emacs Lisp thread runs,
>> while some other thread modifies its data behind its back.
>
> I'm thinking on a module that *creates* on its own thread some Lisp
> object or objects, not referenced from the main thread, then the
> module's thread and the main thread synchronize to transfer ownership of
> that object (add it to a list, set a variable, whatever.)

Not sure about traditional GC, but IGC allocation points are strictly
per-thread.  As with multi-threaded alloc.c allocation, it's a bit of a
theoretical rule: in practice, the race window is quite small, and the
MPS code makes no attempt to verify the per-thread assumption holds, so
you might be able to get away with ignoring concurrency concerns.

Is this hypothetical?  If it isn't, and you want some inspiration about
how to handle "threads" that assume most memory is never shared and
accesses shared memory in special ways, I believe Perl used to do that.

> That would be a quite interesting thing to have, IMO. However, as long
> as the module's thread has to allocate Lisp objects, it may end invoking
> gc.

I recently learned that allocating a bignum or a cons, for example,
never invokes alloc.c GC.  So allocation changes from "doesn't involve
GC" to "might trigger GC, and must be done on the right thread".

> If MPS takes care of interrupting all mutator threads to do the gc
> and we have the guarantee that MPS can interrupt a mutator at any time
> without issues, everything should be fine, no?

GC should be fine, allocation is tricky.

Pip