Re: Releasing the thread global_lock from the module API

[sbaugh@catern.com]

tomas@tuxteam.de writes:
> 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.

It is currently possible: this is what thread-yield, sleep-for, and
accept-process-output do when run from a Lisp thread.  The thread pauses
execution and other threads execute.  This has worked since the
introduction of thread support.