From: Spencer Baugh <sbaugh@catern.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: sbaugh@janestreet.com, emacs-devel@gnu.org
Subject: Re: Releasing the thread global_lock from the module API
Date: Sat, 02 Mar 2024 20:33:05 +0000 (UTC) [thread overview]
Message-ID: <87le70jrwr.fsf@catern.com> (raw)
In-Reply-To: <868r30pnxv.fsf@gnu.org>
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.
next prev parent reply other threads:[~2024-03-02 20:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 14:53 Releasing the thread global_lock from the module API Spencer Baugh
2024-03-01 16:47 ` Eli Zaretskii
2024-03-01 17:34 ` Spencer Baugh
2024-03-01 18:44 ` Eli Zaretskii
2024-03-01 19:02 ` Spencer Baugh
2024-03-01 19:26 ` Eli Zaretskii
2024-03-01 19:51 ` Spencer Baugh
2024-03-01 20:42 ` Eli Zaretskii
2024-03-01 21:21 ` Spencer Baugh
2024-03-01 21:34 ` Eli Zaretskii
2024-03-01 21:56 ` Spencer Baugh
2024-03-02 6:43 ` Eli Zaretskii
2024-03-02 16:39 ` sbaugh
2024-03-02 17:02 ` Eli Zaretskii
2024-03-02 20:33 ` Spencer Baugh [this message]
2024-03-03 6:13 ` Eli Zaretskii
2024-03-03 13:19 ` sbaugh
2024-03-03 15:42 ` Dmitry Gutov
2024-03-03 15:51 ` Eli Zaretskii
2024-03-01 19:30 ` tomas
2024-03-01 23:53 ` Dmitry Gutov
2024-03-02 5:57 ` tomas
2024-03-02 15:35 ` Dmitry Gutov
2024-03-02 16:31 ` tomas
2024-03-02 21:41 ` sbaugh
2024-03-03 6:25 ` tomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le70jrwr.fsf@catern.com \
--to=sbaugh@catern.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.