Re: Releasing the thread global_lock from the module API

[tomas]

On Sat, Mar 02, 2024 at 05:35:26PM +0200, Dmitry Gutov wrote:
> On 02/03/2024 07:57, tomas@tuxteam.de wrote:
> > On Sat, Mar 02, 2024 at 01:53:05AM +0200, Dmitry Gutov wrote:
> > > On 01/03/2024 21:30, tomas@tuxteam.de wrote:
> > > > > - Unrelated Lisp thread B is able to take the global lock and run 
> > > > > Lisp code
> > > > >     in parallel with module_work on thread A.
> > > > > - On thread A, module_work finishes and returns to Lisp.
> > > > Why has thread A wait up to here? This is what's keeping your thread B
> > > > from playing, no?
> > > 
> > > I imagine thread A will want to continue its execution when the results of
> > > the "Emacs-independent work" arrive.
> > 
> > In that case, I think your only choice would be to "pass the continuation":
> > in A, stash away whatever you need to continue, let A die, and when things
> > "come back", start a thread A' to pick up where A left.
> 
> Almost, except "suspend/yield" instead of "let A die".

This only if you can let Lisp suspend/yield safely -- i.e. in a way nothing
bad happens if someone else gets a turn at playing the "interpreter" [1].

I don't think this is currently possible.

Cheers

[1] Well, with a compiler and that, you'd call it a "runtime", but the
   intention should be clear.

Cheers
-- 
t

signature.asc
Description: PGP signature