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: Mon, 10 Jul 2023 11:37:51 +0000 Message-ID: <87bkgk6lps.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <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> <17bc586130847440bbf6@heytings.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="8794"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , luangruo@yahoo.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 10 13:38:51 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 1qIpEB-00023j-BY for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Jul 2023 13:38:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIpDQ-0005uq-Aa; Mon, 10 Jul 2023 07:38:04 -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 1qIpDO-0005ub-BM for emacs-devel@gnu.org; Mon, 10 Jul 2023 07:38:02 -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 1qIpDM-0003Iw-6a for emacs-devel@gnu.org; Mon, 10 Jul 2023 07:38:02 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1F83E240027 for ; Mon, 10 Jul 2023 13:37:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688989078; bh=Ysw2e287sBfDwbP+gIZEIRiXTd0ByG7ylSsK7Ma/R2E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=UkbPoFZu7KG/naqUeOlBSQI+o/9zfcgwdNcOLZ++tk0jxxNz7SbMIaWTSsAXutQQF u/Au8hWI9ThmUQeqxO6l/kKvGLeGHRynCOzY4UEZozK4tPwJSUbKY6zRpf78dESI6r 9Rac5MTWh0kcpmfb58P0n0vvAlQ5MMQ9Jcn8z9aLAa/AsMcInCSCMZUEjs7Tjp237y b2pQmWrMWMf0GNw4po+VnGRkb7HgabxoqUDTvIuqeE8dhW0vKduMx78lgGmdmSTV8e HuVm6CuHCOquZQydIuwf8n7g4oPDxDQC156BaskEYBkkWsQOuqge5PtqNQOtJvnNeQ 7EmUyzyMzGS9A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R027467M7z6twJ; Mon, 10 Jul 2023 13:37:51 +0200 (CEST) In-Reply-To: <17bc586130847440bbf6@heytings.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=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:307712 Archived-At: Gregory Heytings writes: >> 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). That's already similar for cooperative threads. The difference is that sudden changes are limited to `thread-yield', while async threads will have to be written keeping in mind that global variables may be changed during execution unless explicitly locked. And yes, we will need to implement locking on Elisp object level and also on Elisp variable level. But the very need to access global Elisp variables/objects from async threads should not be considered a good practice (except near start/end of thread execution). Most of processing should be done using threads' local lexical scope. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at