On Fri, Mar 01, 2024 at 12:34:36PM -0500, Spencer Baugh wrote:

[...]

> We can't do:
> - Lisp thread A calls module_work
> - On thread A, module_work releases the global lock.
> - On thread A, module_work starts native threads X and Y,
>   and does Emacs-independent work across all of these threads in parallel.

If X and Y are truly independent of the Lisp machinery, I don't
understand what keeps you from sending both their ways and
terminating thread A, thus setting Lisp free for whatever other
thread wants to take over.

> - 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?

Cheers
-- 
t