Re: Releasing the thread global_lock from the module API

[Dmitry Gutov <dmitry@gutov.dev>]

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.