|
From: | Dmitry Gutov |
Subject: | Re: Releasing the thread global_lock from the module API |
Date: | Sun, 3 Mar 2024 17:42:30 +0200 |
User-agent: | Mozilla Thunderbird |
On 03/03/2024 15:19, sbaugh@catern.com wrote:
How about this: native_output = env->call_without_lock(some_native_function, native_input); call_without_lock would be a function which releases the global lock, calls a specified function, then acquires the global lock again.Sorry, I don't agree to adding such interfaces to Emacs. And if you are still not convinced, let's agree to disagree.That is understandable, but I think you are not yet appreciating that this can be a very useful way to introduce parallelism with high performance. And that env->call_without_lock is no less safe than the method you suggested using. Is there anything that would convince you of such things?
Perhaps some data from benchmarking real-life code?For example, you could take the route proposed by Eli, implement your intended workload, make some measurements, and then try to calculate whether the native thread creation overhead makes a noticeable difference.
[Prev in Thread] | Current Thread | [Next in Thread] |