Re: Releasing the thread global_lock from the module API

[Dmitry Gutov <dmitry@gutov.dev>]

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.

Said work might look like making a network request (as Spencer 
outlined), getting a response, parsing the received JSON structure (not 
into Lisp objects yet, just into the native data structures provided by 
the library), and potentially filtering the parsed structure as well.

Then the lock is re-acquired (which will naturally involve some spinning 
waiting for it), and the parsed data is converted into Lisp structures.