From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: Releasing the thread global_lock from the module API Date: Sat, 02 Mar 2024 20:33:05 +0000 (UTC) Message-ID: <87le70jrwr.fsf@catern.com> References: <86cysdrja3.fsf@gnu.org> <86a5nhrdv0.fsf@gnu.org> <868r31rbxn.fsf@gnu.org> <865xy5r8e3.fsf@gnu.org> <864jdpr5zy.fsf@gnu.org> <8634t9qgl2.fsf@gnu.org> <87plwck2q5.fsf@catern.com> <868r30pnxv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16097"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 02 21:33:59 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rgW3S-0003wC-Ks for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Mar 2024 21:33:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgW2g-0001IL-DD; Sat, 02 Mar 2024 15:33:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgW2f-0001Hx-6T for emacs-devel@gnu.org; Sat, 02 Mar 2024 15:33:09 -0500 Original-Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rgW2d-0005Eq-BJ for emacs-devel@gnu.org; Sat, 02 Mar 2024 15:33:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=xAT9bTD8jcfc4u6rFBzgix932ZbHc3Q01HvHS3e5lag=; b=Bc2g7sS/DjFebLcDJmOJakaZuedIiLJgqfB2+D3SDZKoCGpzZ5t7N98U4V4y0L1tv6wh EivbaZp8gI25yJp3xTh8NxRG5jq3DeXh89nfizIvfgYoak25UZwW0PkCARVsrLLrbL1GMg D5W5bpm/G8OZsqhwhlfDR9zm3cNns5DT4jsTnEK57vf0E+0AYDVksKtZgMLkq2nUlY8a/l IgLRnw9p5jb4VbmeidlkqWek2Wr0AeZQDd09Cx7zmsjYKU4r+fk8bitvppngozQjrb24oi zRIgZUlApn/2E69WF6tCn5tkbZx6+St2tXCP6M5PRzcb9xv7ACJkw8nGaKsqr8zQ== Original-Received: by recvd-ffd958f-gzlrt with SMTP id recvd-ffd958f-gzlrt-1-65E38D01-1D 2024-03-02 20:33:05.670961613 +0000 UTC m=+254577.657354314 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-25 (SG) with ESMTP id yW-o3WlSSImL_y3379n1uA Sat, 02 Mar 2024 20:33:05.563 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=68.160.221.150; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Original-Received: from localhost (unknown [68.160.221.150]) by earth.catern.com (Postfix) with ESMTPSA id F2212624F3; Sat, 2 Mar 2024 20:32:52 +0000 (UTC) In-Reply-To: <868r30pnxv.fsf@gnu.org> X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?= =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCgsRxSBnsa9wOJ1Ga7?= =?us-ascii?Q?GAmoD=2FRSxJkUfN8zGsH4UDPKL84ria=2Fw5hGB9tz?= =?us-ascii?Q?LtBNaCs4OU4hkLOy2b6T+DUeqxc6dlCD2E8dcGT?= =?us-ascii?Q?wXvpddyx4dAdU=2Flb=2Fu7x8ENPW0rxdAFMrZZkSVt?= =?us-ascii?Q?ReDV3kveY9Tchm3Nk=3D?= X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Received-SPF: pass client-ip=149.72.126.143; envelope-from=bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com; helo=s.wrqvtzvf.outbound-mail.sendgrid.net X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316706 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 02 Mar 2024 16:39:26 +0000 (UTC) >> Cc: Spencer Baugh , 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.