Re: Releasing the thread global_lock from the module API

[Spencer Baugh <sbaugh@catern.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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).

Because a Lisp program that uses a native module might make thousands of
module calls.  This is fine when each call takes a microsecond.  If we
add, for example, 500 microseconds of overhead to each module call, then
1000 module calls will take half a second.

For example: I have a project.el backend which uses a native module.
Looking up the project for the current directory and then getting the
name of the project makes around 5 module calls.  I have around 200
projects.  That works out to 1000 module calls to get the names of all
my projects.  Currently with the native module backend this takes around
a millisecond.  With 500 extra microseconds per call, it will take half
a second.

>> 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.

Yes.  But of course in practice we would find a design which allows
releasing the lock but is hard to misuse.

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.

That seems hard to misuse.  It is about equivalent to:

   native_output = run_in_native_thread(some_native_function, native_input);

which is possible today for module programmers.  Just, call_without_lock
would be much faster.