From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.devel Subject: Re: Releasing the thread global_lock from the module API Date: Sat, 2 Mar 2024 06:57:00 +0100 Message-ID: References: <86cysdrja3.fsf@gnu.org> <470c6bea-805d-42dd-8bbd-936ea93c6579@gutov.dev> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R5uGPYGZsqCazTHS" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15770"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 02 06:58:12 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 1rgINw-0003wn-Gn for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Mar 2024 06:58:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgIMy-0002gp-MC; Sat, 02 Mar 2024 00:57:12 -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 1rgIMu-0002gN-FT for emacs-devel@gnu.org; Sat, 02 Mar 2024 00:57:08 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgIMr-0000lF-CJ for emacs-devel@gnu.org; Sat, 02 Mar 2024 00:57:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4pYTxy1ajA5GySDCNr2GT0xl+6kQ5xOXyA8NPHeGFNg=; b=Zs3Li4otyfQ+wTO07RXR9Iov2A ZufViCoYGsV3snERlP3gL4rn5IHVOz7DprMnjJLbFzu4NOmDB5eMnASKsjJlgEbIzbaLFwYXqNhhy 5Nj4znJn5wHaZGUp4cF2fmd0LWHlgTLIv0+5pQ2UIhHhrxEbfKjx0MauuRAr4c/9OQQ3ff4QFs+z7 rRoh8Uvf41O1NvwBx4BNNv+qwR8OYjMNb94fdKhVtRSUwMwEIhYGP/vFhFW+ELR2nlcZLHzagBPgX qGQKn9FYG6Q0tYLJyOxbV73u9vcjxdb93hfJhxnotj6M9XXo6WPsNChar5fW1Cynf2idhEBHEp7kA VbM1nhlA==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1rgIMm-00050z-1T; Sat, 02 Mar 2024 06:57:00 +0100 Content-Disposition: inline In-Reply-To: <470c6bea-805d-42dd-8bbd-936ea93c6579@gutov.dev> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:316689 Archived-At: --R5uGPYGZsqCazTHS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 Lis= p 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? >=20 > 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. > Said work might look like making a network request (as Spencer outlined), > getting a response, parsing the received JSON structure (not into Lisp > objects yet, just into the native data structures provided by the library= ), > and potentially filtering the parsed structure as well. >=20 > Then the lock is re-acquired (which will naturally involve some spinning > waiting for it), and the parsed data is converted into Lisp structures. I'm always wary when people call for "threads" when they mean concurrency. The javascript/browser folks do it all the time with explicit continuations and don't seem to care. It's messier in one way, but when you start locking and potentially deadlocking, threads have their own ways of messiness, as the Java folks know all too well (sometimes I have the hunch that those two messineesses are complementary in some weird way ;-) As sketched above, you can even combine things (I'd be scared to do, but there you go). Real threads, IMO, only really help you in some cases: - when you really want more than one CPU core working on your stuff (and distributing to several processes is not an option) - when you have to use some lower level lib which blocks (and you can't afford to take it apart and re-implement it non-blocking) My experience (this was mostly plain old C), once you've wrapped your head around continuation style, it is far easier to debug. Cheers --=20 t --R5uGPYGZsqCazTHS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZeK/pAAKCRAFyCz1etHa RpkJAJ9Fvapp/6CF1Ntn/Z4DuZVXmjcKYACfWCO2uKX/aTBOoABlNM7QuB2Ap+E= =PaxG -----END PGP SIGNATURE----- --R5uGPYGZsqCazTHS--