From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Sat, 08 Jul 2023 08:16:39 +0000 Message-ID: <87wmzaakd4.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22478"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 08 10:17:01 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 1qI37l-0005fb-K7 for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jul 2023 10:17:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qI37Z-0005sO-7q; Sat, 08 Jul 2023 04:16:49 -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 1qI37W-0005rt-OQ for emacs-devel@gnu.org; Sat, 08 Jul 2023 04:16:46 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qI37U-0001Yv-2W for emacs-devel@gnu.org; Sat, 08 Jul 2023 04:16:46 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id DB83A240028 for ; Sat, 8 Jul 2023 10:16:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688804200; bh=NbfXfCEpBiv967BpB1a4fI3LOKtZ4nJHKUF1iTqbY00=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=iZvo7nJrS0JG7HBpZuF9zl8h/clFsJ+BsdbaFqpl5HGhW8ox2Q0crXJTaQPJhqa6N RzH+JQ8zkzwlJ57wB+EtdC4FE95PK9cEW2sQwTpNfwNkbNVaJOIAQuLRvtEMntEGjk CAaLe02upY3PSetzCV+5C4N3uFrgt8CYjP7nYV2mF5Subo4LgYNtTJwMY2vKULMSUQ 9pMbzObC4uN6UpSa454GjuJY0DJHoeB7AeK+8P2JqdqclKi3w61EJJl3/ZPr4JVQ47 yfswlra4RgJwJKKKtY/jaguwGpkH3Oc522AdN+MKLIIOsPEbUKPGiKyJmzv4BPn3X3 Y5je51V5hME9w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Qyjlr1CfSz9rxB; Sat, 8 Jul 2023 10:16:39 +0200 (CEST) In-Reply-To: <83zg46dexg.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:307604 Archived-At: Eli Zaretskii writes: >> My idea with isolated thread is similar to having a bunch of state >> variables coped to the thread before executing it. Interlocking will >> still be necessary if the isolated thread wants to do anything with the >> actual global state (like buffer modification, for example). > > How would we know which part(s) of the global state to copy, and how > will the Lisp program running in the thread know which variables it > can safely access? This is a difficult question. On one hand, it does not make sense to copy everything - it will imply multiplying Emacs memory footprint. On the other hand, we cannot know in advance which variables will actually be used by a thread. 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. 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. The range of variables that can be made remote should be minimized and possibly also restricted to a safe subset of variables. > ... 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. > ...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. But programs that only return a value will work as usual, without a need to modify them. 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at