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: Sat, 08 Jul 2023 13:13:18 +0300 Message-ID: <83fs5yd83l.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <87jzve8r4m.fsf@localhost> <871qhmo5nv.fsf@yahoo.com> <87bkgq8p5t.fsf@localhost> <831qhmjwk0.fsf@gnu.org> <875y6y8nlr.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> <83cz13g811.fsf@gnu.org> <87lefrbvjw.fsf@localhost> <83h6qfecxt.fsf@gnu.org> <87ttuffcnv.fsf@yahoo.com> <835y6uex7z.fsf@gnu.org> <87zg46aowt.fsf@localhost> <83zg46dexg.fsf@gnu.org> <87wmzaakd4.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16608"; 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 Sat Jul 08 12:14:05 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 1qI4x2-00045l-Nv for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 12:14:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI4wI-0005ba-Lm; Sat, 08 Jul 2023 06:13:18 -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 1qI4wG-0005bJ-Eu for emacs-devel@gnu.org; Sat, 08 Jul 2023 06:13:16 -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 1qI4wG-0004Sd-25; Sat, 08 Jul 2023 06:13:16 -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=X3o9AtHZLcjkEnfWdkJbHeo0ZZ6gb1WzWPjWr3eKL1o=; b=AX+tXBavJK2w TcihQHH5ct/cpKcb4k4U63+4i5yeHg6yoZeQ9mPB/c8rFcKUtrVY8AlSLP6yPjK2J4V4fSoEGMPH6 veIaVjmMHQ66B5fkqoCQ6H6So5JwqvQzj+Z1/FnW3Dc/sq3J8SOZIBHwX8uSVs+06j8OIXRLJ+USh YIdlIyuYriW/tCIxo5fIqGgN5CogiYTgzEUM7hmgR4seIHqXY5B3+5jcfET4RbPUgVD13vsggpREw HGQkv5+XzXmxF146eJXFmP35AhjLRI6JYL/Ke+nB1a+qpcfcQFu+A0+x5FH1KRd2I3+V842DEdkwR 3o6v+DcLG/FaATfOVWE+rA==; 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 1qI4wF-0004kf-B7; Sat, 08 Jul 2023 06:13:15 -0400 In-Reply-To: <87wmzaakd4.fsf@localhost> (message from Ihor Radchenko on Sat, 08 Jul 2023 08:16:39 +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:307609 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Sat, 08 Jul 2023 08:16:39 +0000 > > Eli Zaretskii writes: > > So, it can be something like copy-on-read - the child thread will copy > the necessary values from parent thread as running Elisp code needs > them. > > By default, such copy will not be synchronized with the parent Emacs > thread, so that we do not need to worry about parent thread changing the > values asynchronously. When does such synchronization happen, though? Imagine some long-running thread which does some periodical processing: when and how will such a thread synchronize with the actual state of the variables it needs? How will this look from the POV of Lisp code running in this thread? (This proposal also means significant implementation problems.) > Manually, it may also be allowed to create "remote" values that will > query the other thread: thread 1 will hold (foo = '(1 2 3)) and thread 2 > will hold (foo = #). Then, thread 2 requesting to read/write > value will query thread 1. A thread running Lisp cannot be queried, unless it somehow "listens" to such queries. This isn't magic, it has to be implemented, and how do you envision to implement it? You envision some kind of scheduler as part of Emacs? something else? > The range of variables that can be made remote should be minimized and > possibly also restricted to a safe subset of variables. I very much doubt such a "safe subset" exists that can support useful Lisp programs. > > ... If I am the Lisp programmer writing code for such > > a thread, how can I know what is and what isn't allowed? > > Everything is allowed, but global state changes will not necessarily > propagate to the parent Emacs thread. They will be confined to that > child async thread. So it could be that a thread decides, for example, that some buffer B is the return value of its function, whereas buffer B no longer exists because it was killed? How's that useful? > > ...And what > > happens if I do something that is not allowed? And finally, does it > > mean we cannot run existing Lisp programs in such threads, but must > > program for them from scratch? > > Non-trivial programs that need to modify the global Emacs state will > have to be written specially. So you basically agree that to have useful enough multi-threading, most of Emacs will have to be redesigned and rewritten? > But programs that only return a value will work as usual, without a > need to modify them. How many programs like that exist and are useful? > The idea is similar to https://github.com/jwiegley/emacs-async (or to > `org-export-async-start'), but with more tight communication between > Emacs processes. The original emacs-async requires a new Emacs instance > that will also need to re-load all the necessary packages manually from > startup. If we will have the same disadvantages and restrictions as in emacs-async, then why bother? emacs-async already exists.