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: Fri, 01 Mar 2024 20:44:35 +0200 Message-ID: <86a5nhrdv0.fsf@gnu.org> References: <86cysdrja3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40416"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 01 19:45:45 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 1rg7tA-000AG8-Ji for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Mar 2024 19:45:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rg7s9-0000KP-JC; Fri, 01 Mar 2024 13:44:41 -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 1rg7s7-0000Je-0Z for emacs-devel@gnu.org; Fri, 01 Mar 2024 13:44:39 -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 1rg7s6-0001h4-GS; Fri, 01 Mar 2024 13:44:38 -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=7Z4ifS8QYfOyJs9vE1ytVgX4qRP3a/9YFjkVfPI4pcY=; b=YDchXW9XVULr caTgrcuqxWrKmP5SQAhq0jmcTAeCs36iLEtLf2MF9rX89AFZMlJ4TJNU1k5tuGqAj92uZor7pNX+c Yo4K5Ss/J66rK5U6hxFj6GrKafsyuVGrc34yy05pH2Ms9/b1AWWdd+TmzgldaoRxy66g6FGC8oeVF 4yhkzhDT4Qf40PoutKI/Rtn3STxKVM7eJL49F/Iwj5cPGaIiw4q/W2Rtdak8znZCVM+GZ6y513fNm +7IKEOiZb2snyZkKc7m/YTgUDCm4SpQiN5M4S6eQWtCqIaJfnCHXRXIegkQ/HzfqaedclZd9ja1ri aLCutJ9AEeJx1gGDlfPaKQ==; In-Reply-To: (message from Spencer Baugh on Fri, 01 Mar 2024 12:34:36 -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:316673 Archived-At: > From: Spencer Baugh > Date: Fri, 01 Mar 2024 12:34:36 -0500 > > Eli Zaretskii writes: > > > It isn't clear what exactly do you want added, since calls to > > thread-yield and similar APIs (like sleep-for and > > accept-process-output), which release and re-acquire the global lock, > > are already possible from Lisp threads. What exactly is missing? > > Those release and re-acquire the global lock, yes, but they don't allow > module code to run on the thread while the global lock is released. That's because the Emacs Lisp thread machinery cannot allow that. A Lisp thread has full access to the Emacs global state, so we cannot allow more than one thread to have that at the same time. > We can't do: > - Lisp thread A calls module_work > - On thread A, module_work releases the global lock. > - On thread A, module_work starts native threads X and Y, You can do that if the native threads are started before releasing the global lock. > and does Emacs-independent work across all of these threads in parallel. What do you mean by "Emacs-independent work across all of these threads in parallel"? If you want to break out of the restriction of having only one Lisp thread running at any given time, then this is IMO impossible without redesigning and reimplementing the current threads machinery. > Releasing the global lock allows Lisp thread B to run while Lisp thread > A is running the module. As explained above, you can do that already. > > I think this is already possible, see above. I guess I'm missing > > something. > > I don't think it is. How would a module release global_lock, call a C > library function on the current thread, and then re-acquire the global > lock? Can you say how you would do that with the APIs we have today? If a thread releases a global lock, it cannot run the Lisp machine until it re-acquire the global lock. So what you want is impossible within the current threads framework, unless you start native (non-Lisp) threads which cannot safely access the Emacs global state.