From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Releasing the thread global_lock from the module API Date: Sun, 03 Mar 2024 13:19:04 +0000 Message-ID: <87cysbjvw7.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> <87le70jrwr.fsf@catern.com> <864jdnq1vx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35333"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:V3QAFOrA0wVEWcrQHhQiC3KotgQ= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 03 16:35:52 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 1rgnsW-0008wD-BX for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Mar 2024 16:35:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgnrm-0004Di-4P; Sun, 03 Mar 2024 10:35:06 -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 1rglkX-0002y7-SC for emacs-devel@gnu.org; Sun, 03 Mar 2024 08:19:30 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rglkW-0007tQ-8l for emacs-devel@gnu.org; Sun, 03 Mar 2024 08:19:29 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rglkT-0002h8-NP for emacs-devel@gnu.org; Sun, 03 Mar 2024 14:19:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 03 Mar 2024 10:35:04 -0500 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:316756 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Sat, 02 Mar 2024 20:33:05 +0000 (UTC) >> Cc: sbaugh@janestreet.com, emacs-devel@gnu.org >> >> >> 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. > > A module whose call takes this little time to complete and whose calls > from Lisp are so massive should not, and need not, use this technique, > because releasing the global lock for such a short time will not > benefit anything. Releasing a global lock is only beneficial if a > module call does a lot of work, during which other Lisp threads could > do something useful. but if a module call takes a significant time > (say, a few seconds), then adding a 20 usecs to that time is > insignificant. Yes, to avoid the thread creation overhead, a native module should only create a native thread to run some_native_function if the native module knows that some_native_function will take a long time. Unfortunately, most of the time a native module can't know how long some_native_function will take before calling it. For example, native functions which make network calls might return immediately when there's already data available from the network, but will have to send new network requests sometimes. Or, native functions which provide an in-memory database might be fast or slow depending on the database contents. Since the native module doesn't know if some_native_function will take a long time, the native module needs a way to allow some_native_function to run in parallel which is cheap, so the native module can do it for all calls to some_native_function. >> >> 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. > > Sorry, I don't believe this is reliably possible, or safe enough to > justify exposing the lock to Lisp. Certainly not to modules, which is > an open-ended gateway into the bowels of the Emacs Lisp machine. > >> 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. > > Sorry, I don't agree to adding such interfaces to Emacs. And if you > are still not convinced, let's agree to disagree. That is understandable, but I think you are not yet appreciating that this can be a very useful way to introduce parallelism with high performance. And that env->call_without_lock is no less safe than the method you suggested using. Is there anything that would convince you of such things?