emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/igc: Implications of MPS being asynchronous


From: Óscar Fuentes
Subject: Re: scratch/igc: Implications of MPS being asynchronous
Date: Sun, 12 Jan 2025 16:35:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]