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: Sat, 02 Mar 2024 21:41:38 +0000 (UTC) Message-ID: <87h6hojoqi.fsf@catern.com> References: <86cysdrja3.fsf@gnu.org> <470c6bea-805d-42dd-8bbd-936ea93c6579@gutov.dev> <19d51eaa-0f98-4542-9d08-0e9d23224dc4@gutov.dev> 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="23650"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Dmitry Gutov , Spencer Baugh , emacs-devel@gnu.org To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 02 22:42:08 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 1rgX7P-0005yC-6F for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Mar 2024 22:42:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgX72-0001L6-0q; Sat, 02 Mar 2024 16:41:44 -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 1rgX70-0001Kp-AU for emacs-devel@gnu.org; Sat, 02 Mar 2024 16:41:42 -0500 Original-Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rgX6y-0001y4-Ok for emacs-devel@gnu.org; Sat, 02 Mar 2024 16:41:42 -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=61UUsrcLpYdLTzHRtJzwJPYql5jpyJoDAzAmuK0nDZo=; b=bAHZK7Cku9FErUbKNtzibMpsE5vEwI/YnLTqtBiw/+KI2pUDdgoZsTY/QSht1gzk8ZfS RKGSnimJK37Stzf7kkf6TcYVpv2jNcxVXPNrLpB+K3JzQciBA8qZP7zSy+N2r8AwgOCcFC bYqJkY0TDGnXxn0jupGWrX0HGN5jFNGNcXaJINHPfAKsKiilo4ufcUqbPnIJuHSnKOWj5S Teun25JJElAbuccUnCgosGiugLZG7srdM8o9rmjdxsL3+ddCmC5zQiHtHv6Vouq+Ryiqak Fq+dU+OsmZpqjJxFI+kwsd0pXuKH5CLjeWcgjuG75MQKEF4ucKE6k8oIIlgUVF3g== Original-Received: by recvd-67cf556c4d-46fnv with SMTP id recvd-67cf556c4d-46fnv-1-65E39D12-F 2024-03-02 21:41:38.378186305 +0000 UTC m=+258685.255030923 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-28 (SG) with ESMTP id _YTBPCjkSeq4w46YfdgrTg Sat, 02 Mar 2024 21:41:38.288 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=68.160.221.150; helo=localhost; envelope-from=sbaugh@catern.com; receiver=tuxteam.de Original-Received: from localhost (unknown [68.160.221.150]) by earth.catern.com (Postfix) with ESMTPSA id 23936624F4; Sat, 2 Mar 2024 21:41:25 +0000 (UTC) In-Reply-To: (tomas@tuxteam.de's message of "Sat, 2 Mar 2024 17:31:55 +0100") X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJb1zQ4EY3iv1r=2FtkwugR?= =?us-ascii?Q?Nz91aWEo2XAS+5NjfUjj3b1iD+Bmkbmpl2OugIg?= =?us-ascii?Q?nsNqH9I2E7UNsNOlHmwyX8j1pzj2MRQY90euc=2F1?= =?us-ascii?Q?Ku4c+jouOTWUt2mWBGUk0W0l=2F0+kB=2FCYS115FJz?= =?us-ascii?Q?HxEqCfwoFriMv1zWDdLdDf6rhQRCoZ7aJDA=3D=3D?= X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Received-SPF: pass client-ip=149.72.154.232; envelope-from=bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com; helo=s.wrqvwxzv.outbound-mail.sendgrid.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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=ham 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:316710 Archived-At: tomas@tuxteam.de writes: > On Sat, Mar 02, 2024 at 05:35:26PM +0200, Dmitry Gutov wrote: >> On 02/03/2024 07:57, tomas@tuxteam.de wrote: >> > On Sat, Mar 02, 2024 at 01:53:05AM +0200, Dmitry Gutov wrote: >> > > On 01/03/2024 21:30, tomas@tuxteam.de wrote: >> > > > > - Unrelated Lisp thread B is able to take the global lock and run Lisp code >> > > > > in parallel with module_work on thread A. >> > > > > - On thread A, module_work finishes and returns to Lisp. >> > > > Why has thread A wait up to here? This is what's keeping your thread B >> > > > from playing, no? >> > > >> > > I imagine thread A will want to continue its execution when the results of >> > > the "Emacs-independent work" arrive. >> > >> > In that case, I think your only choice would be to "pass the continuation": >> > in A, stash away whatever you need to continue, let A die, and when things >> > "come back", start a thread A' to pick up where A left. >> >> Almost, except "suspend/yield" instead of "let A die". > > This only if you can let Lisp suspend/yield safely -- i.e. in a way nothing > bad happens if someone else gets a turn at playing the "interpreter" [1]. > > I don't think this is currently possible. It is currently possible: this is what thread-yield, sleep-for, and accept-process-output do when run from a Lisp thread. The thread pauses execution and other threads execute. This has worked since the introduction of thread support.