From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Releasing the thread global_lock from the module API Date: Sat, 02 Mar 2024 19:02:04 +0200 Message-ID: <868r30pnxv.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9568"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 02 18:03:36 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 1rgSls-0002Ge-7h for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Mar 2024 18:03:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgSkY-0000dg-4w; Sat, 02 Mar 2024 12:02:14 -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 1rgSkW-0000Wq-Er for emacs-devel@gnu.org; Sat, 02 Mar 2024 12:02:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgSkU-0000cj-SG; Sat, 02 Mar 2024 12:02:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UMzt45Ub1bKrZEl86lGNv/UVYAHkidt2TOT8dGHnDkw=; b=T48/HGFbDYFN 91METBR0IWf9hnPSj6ICmRC2oBHBke595zP6PRBHgi5YNeUoQJvH3PGkDnBGIu03KxMplzcO4A6gh 1wQtPnP7NbjXnwBNp/oIp5UJGSDmtPMLZxH8BCNv221AuyVV0vUnwCy6ABhEsUmJVkWzlitToVYv/ imKXpKSMLV2MTR+enrhA7PqHtoaAZyety6TqfKfoiN+MiAkKXL8XjjnVPB48Zn8fp7eQyx55afI/y LrTnK2aVoSladV/glGAYP7f25hVPni61bRM/5Wr84HL1M88RBm2BvFpqnsCltg+QvZDPgPRKJBA29 jjH5vsAxJlM+MBN0xmadkg==; In-Reply-To: <87plwck2q5.fsf@catern.com> (sbaugh@catern.com) 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:316704 Archived-At: > 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). > 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. I'm afraid we will have to live with the 0.1 msec overhead. > Releasing the lock is essentially free Nothing is ever free in the world of synchronization primitives. But that's a btw, not the most important aspect of this.