Re: Releasing the thread global_lock from the module API

[Eli Zaretskii <eliz@gnu.org>]

> From: sbaugh@catern.com
> Date: Sat, 02 Mar 2024 16:39:26 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh@janestreet.com>, emacs-devel@gnu.org
> 
> Oh, yes, that is similar to what I'm proposing.
> 
> Just to summarize, if call_into_native_module looks like:
> 
> emacs_value call_into_native_module(emacs_env *env, emacs_value input) {
>   native_value native_input = convert_to_native(env, input);
>   native_value native_output;
> 
>   [...some code...]
> 
>   return convert_to_emacs(env, native_output);
> }
> 
> Then the current state of the world ("hold the lock" model):
> 
>   native_output = some_native_function(native_input);
> 
> If I understand correctly, you are proposing (the "new thread" model):
> 
>   native_thread_handle handle = native_thread_create(some_native_function, native_input);
>   while (!native_thread_done(handle)) {
>     emacs_thread_yield(env);
>   }
>   native_output = native_thread_result(handle);
> 
> And I am proposing (the "release lock" model):
> 
>   release_global_lock(env);
>   native_output = some_native_function(native_input);
>   acquire_global_lock(env);
>   
> All three of these are used in the same way from Lisp programs.  But the
> "new thread" and "release lock" models have the advantage over the "hold
> the lock" model that if called from a Lisp thread, that Lisp thread will
> run some_native_function in parallel with Lisp execution on other Lisp
> threads, including the main Emacs thread.
> 
> To check my understanding: does this all seem correct so far, and match
> your proposal?

Yes.

> So, the main difference between the "new thread" model and the "release
> lock" model is that creating a native thread takes a nontrivial amount
> of time; maybe around 0.1 milliseconds.  If some_native_function would
> takes less time than that, the thread creation cost will slow down
> Emacs, especially because the native module creates the native thread
> while holding the Lisp global_lock.

Why are you worried by 0.1 msec slowdown (if it indeed takes that
long; I think it should be around 10 to 20 usec at most)?  If this
kind of slowdown is important for you, you are using the wrong
software package (and probably the wrong OS as well).

> The "release lock" model fits this need.

But it exposes the sensitive internals and runs the risk of more than
one Lisp thread running at the same time, and thus is not acceptable.
I'm afraid we will have to live with the 0.1 msec overhead.

> Releasing the lock is essentially free

Nothing is ever free in the world of synchronization primitives.  But
that's a btw, not the most important aspect of this.