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: Concurrency via isolated process/thread Date: Sun, 09 Jul 2023 11:41:59 +0300 Message-ID: <834jmdbhns.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87h6qhnalc.fsf@yahoo.com> <87ilax71wo.fsf@localhost> <831qhli14t.fsf@gnu.org> <87wmzdxewc.fsf@localhost> <83r0plgjeo.fsf@gnu.org> <87o7kpxapo.fsf@localhost> <83mt09gcaf.fsf@gnu.org> <87wmzbc3af.fsf@localhost> <87edljhmjq.fsf@yahoo.com> <87fs5zbuwn.fsf@localhost> <871qhjgrku.fsf@yahoo.com> <831qhieumz.fsf@gnu.org> <87lefqg7yl.fsf@yahoo.com> <83h6qed8kw.fsf@gnu.org> <87h6qefwj0.fsf@yahoo.com> <83bkgmcx0q.fsf@gnu.org> <87a5w5gbs4.fsf@yahoo.com> <83bkglbmai.fsf@gnu.org> <87o7kleeub.fsf@yahoo.com> <835y6tbkr2.fsf@gnu.org> <87v8et8qkk.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21026"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 09 10:42:43 2023 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 1qIQ0A-0005HM-Vs for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 10:42:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIPzQ-0007uO-NS; Sun, 09 Jul 2023 04:41:56 -0400 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 1qIPzO-0007uE-Cv for emacs-devel@gnu.org; Sun, 09 Jul 2023 04:41:54 -0400 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 1qIPzN-0006T0-WF; Sun, 09 Jul 2023 04:41:54 -0400 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=GkPP59WjeHPkJlX1Fn1mhS2I55oGYppkQ3LmUX+eBYs=; b=SgtkZuz0t0lI POWjnUmEkDbBDKMHpAOGkJSEZ+1dHLpOhfkFaes4ZyaUXohY06niaCPGpFg1WA4exdK3/tKtNzrXD y6cPeyUn26Phh9Ey7rpnL3GFDelewKq1MG32K1MAdDcf3lD7rXszKR2x8YqBWwhK4PHNOfOuKS9Hx YzzNgTPbXXtqrxUuDDjvuOAPOiWFrqFrBturn2Eh/FyP8W/giUKnsyQZUvifHEEQ77JIbL9l6DHix qhScbI2g4vc2wPDqLeBKGMoQkadB+ZrY+cHbI8JACPjcou97mQUw73lkitoKPUe2dEj4oMs8e0mJV 3vogSY0Uo8Ley+nmrdqmfA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIPzN-0005cB-43; Sun, 09 Jul 2023 04:41:53 -0400 In-Reply-To: <87v8et8qkk.fsf@localhost> (message from Ihor Radchenko on Sun, 09 Jul 2023 07:57:47 +0000) 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:307647 Archived-At: > From: Ihor Radchenko > Cc: Po Lu , emacs-devel@gnu.org > Date: Sun, 09 Jul 2023 07:57:47 +0000 > > Eli Zaretskii writes: > > >> When programmers write such code for other interactive programs, they > >> are comfortable with the limitations of running code outside of the UI > >> thread. Why should writing new, thread-safe Lisp for Emacs be any more > >> difficult? > > > > Because we'd need to throw away 40 years of Lisp programming, and > > rewrite almost every bit of what was written since then. It's a huge > > setback for writing Emacs applications. > > May you please elaborate why exactly do we need to rewrite everything? We already did, please read the previous messages. In a nutshell: because most of the Lisp code we have cannot be run from an async thread. > If we agree that async threads will have limitations, we may as well > start small, allowing a limited number of functions to be used. The > functions that do not support true async will then switch to the > cooperative mode, possibly throwing a warning. > > Later, if it is truly necessary to rewrite things for async, it can be > done gradually. The above exactly means a massive rewrite of a very large portion of Lisp code we have today and use it every day. As long as such a rewrite is not done, "switching to cooperative mode" means that the Lisp programs runs the way it does today, so there will be almost no gain until enough code will be rewritten.