emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Releasing the thread global_lock from the module API


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]