[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Releasing the thread global_lock from the module API
From: |
Spencer Baugh |
Subject: |
Re: Releasing the thread global_lock from the module API |
Date: |
Sat, 02 Mar 2024 20:33:05 +0000 (UTC) |
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.
- Re: Releasing the thread global_lock from the module API, (continued)
- Re: Releasing the thread global_lock from the module API, Spencer Baugh, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Spencer Baugh, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Spencer Baugh, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Spencer Baugh, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/02
- Re: Releasing the thread global_lock from the module API, sbaugh, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/02
- Re: Releasing the thread global_lock from the module API,
Spencer Baugh <=
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/03
- Re: Releasing the thread global_lock from the module API, sbaugh, 2024/03/03
- Re: Releasing the thread global_lock from the module API, Dmitry Gutov, 2024/03/03
- Re: Releasing the thread global_lock from the module API, Eli Zaretskii, 2024/03/03
- Re: Releasing the thread global_lock from the module API, tomas, 2024/03/01
- Re: Releasing the thread global_lock from the module API, Dmitry Gutov, 2024/03/01
- Re: Releasing the thread global_lock from the module API, tomas, 2024/03/02
- Re: Releasing the thread global_lock from the module API, Dmitry Gutov, 2024/03/02
- Re: Releasing the thread global_lock from the module API, tomas, 2024/03/02
- Re: Releasing the thread global_lock from the module API, sbaugh, 2024/03/02