From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Sun, 09 Jul 2023 17:13:41 +0000 Message-ID: <17bc586130847440bbf6@heytings.org> References: <871qhnr4ty.fsf@localhost> <877crd6w53.fsf@localhost> <877crdjiwn.fsf@yahoo.com> <874jmh6v4s.fsf@localhost> <83y1jtgmbw.fsf@gnu.org> <87zg49xfke.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 19:14:40 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 1qIXzc-0006qf-30 for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jul 2023 19:14:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIXyk-00049W-SC; Sun, 09 Jul 2023 13:13:46 -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 1qIXyj-00049F-Cq for emacs-devel@gnu.org; Sun, 09 Jul 2023 13:13:45 -0400 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIXyh-0001E1-PI; Sun, 09 Jul 2023 13:13:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1688922821; bh=awgpAagB6gWVnekeeJfmJb1OuQzGMm0ofd4Ff3kMjFg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=mR2IpXPpssEJRILQA9oPGHR5mJp5Ews39PBmqXYoboj+MOmBvo7KubcZ68OwCbsyl Q4W0SunpKVhTXl/uIaYUsQt7+zVDFeEKyGGyoL9H6gJPfcW6USQqPX9A+SaxomY5Ut yY01kZJVJeKWKO9E539b1IpIaJYE6vTbLD9S+cz3ZR8e/C8HvU54SXrFOoM8glY54q l+0f2zY66Klo/q11Hqh2jzNyObl8j/fPiP4Gp5EuuOhtrATxo51IyasZRD1ovJtHla 12pozDboWB0Gbg5tLErjJS9k8xHz5rDBT2OBaDiQXDgXcCMmbOroUlyEE/9DIoN9zx AjU/00hr0TnzQ== In-Reply-To: <87pm518m0g.fsf@localhost> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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_PASS=-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:307696 Archived-At: >> I don't believe any useful Lisp program in Emacs can be >> side-effect-free, for the purposes of this discussion. Every single >> one of them accesses the global state and changes the global state. > > As I said, I hope that we can convert the important parts of the global > state into thread-local state. > That's not possible alas. Basically Emacs' global state is the memory it has allocated, which is an enormous graph in which objects are the nodes and pointers are the edges. Any object may be linked to any number of other objects (which means that you cannot isolate a subgraph, or even a single object, of the graph), and any non-trivial Elisp function (as well as garbage collection and redisplay) can change any of the objects and the structure of the graph at any time (which means that two threads cannot use the same graph concurrently without both of them taking the risk of finding the graph suddenly different from what it was during the execution of the previous opcode). Given that, the only thing can be done in practice (which is what emacs-async does) is to create another Emacs instance, with another global state, in which some processing is done, and report the result back to the main Emacs instance. The only alternative is to create another Emacs from scratch, with concurrency as one of its design principles. >>> Yes. I mean... look at Haskell. There is no shortage of pure >>> functional libraries there. >> >> I cannot follow you there: I don't know Haskell. > > In short, pure functions in Haskell can utilize multiple CPUs > automatically, without programmers explicitly writing code for > multi-threading support. > The problem is that Elisp is not Haskell, and cannot be converted into something that resembles Haskell. Haskell functions are pure by default (impurity is the rare exception), Elisp functions are impure by default (purity is the rare exception).