[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Releasing the thread global_lock from the module API
From: |
tomas |
Subject: |
Re: Releasing the thread global_lock from the module API |
Date: |
Fri, 1 Mar 2024 20:30:11 +0100 |
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
signature.asc
Description: PGP signature
- Re: Releasing the thread global_lock from the module API, (continued)
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Spencer Baugh, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/02
- Re: Releasing the thread global_lock from the module API, sbaugh, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Spencer Baugh, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/03
- Re: Releasing the thread global_lock from the module API, sbaugh, 2024/03/03
- Re: Releasing the thread global_lock from the module API, Dmitry Gutov, 2024/03/03
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/03
- Re: Releasing the thread global_lock from the module API,
tomas <=
- Re: Releasing the thread global_lock from the module API, Dmitry Gutov, 2024/03/01
- Re: Releasing the thread global_lock from the module API, tomas, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Dmitry Gutov, 2024/03/02
- Re: Releasing the thread global_lock from the module API, tomas, 2024/03/02
- Re: Releasing the thread global_lock from the module API, sbaugh, 2024/03/02
- Re: Releasing the thread global_lock from the module API, tomas, 2024/03/03