Re: scratch/igc: Implications of MPS being asynchronous

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 12 Jan 2025 16:35:06 +0100
> 
> 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.)
> 
> 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. 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?

I don't think our allocation code that creates Lisp objects is
thread-safe, in the sense that it can be running in more than a single
thread at any given time.

Emacs modules are not supposed to create Lisp objects from other
threads.