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, 17 Jul 2023 07:55:40 +0000 Message-ID: <878rbf0y6b.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <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> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <87y1jf29a4.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1544"; 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 Mon Jul 17 09:56:44 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 1qLJ63-0000BQ-Oy for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Jul 2023 09:56:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLJ54-0004Ra-8k; Mon, 17 Jul 2023 03:55:42 -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 1qLJ51-0004RG-11 for emacs-devel@gnu.org; Mon, 17 Jul 2023 03:55:39 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLJ4y-0005Ej-0m for emacs-devel@gnu.org; Mon, 17 Jul 2023 03:55:38 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5BAAB240103 for ; Mon, 17 Jul 2023 09:55:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689580533; bh=Vhyw6ZZ4F9KbhBmWUXs7Rvmd25dcZ/GM+JQAxz8EyF0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=A9dtSh4gMjk3CcgHnt+XVlFSI5AzOYiL/HTinNuEv6sW9BMHOEt49XOOh6wr2YIcy z8qNFfUCfZFY9W2aaOYWb8mxY7Ls/1MUI9OSF0fEYXNPQfR1ZYrYtdaS7Fjd4a/9Hp hjmVyTDKGCXByuSH0tYP96StLVS2pUpmU0jdzLPtO5qOWQHYTNum7eIv9OTgRI0uRq GWXfQClU/aNidXXHuEJWTU/z0oo417EQGnlSkWd3BA/1yyswSVtorBkEPB/1lesm/O /FFFqb37bnbUTGLfgnZrJMYrIZHB3SUiP5rAryNHHXPFtzFG/3Aoiq6ckFSXZDTIOe bR06tULmmmsDA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R4DsJ444Gz9rxV; Mon, 17 Jul 2023 09:55:32 +0200 (CEST) In-Reply-To: <87y1jf29a4.fsf@localhost> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.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=-1, RCVD_IN_MSPIKE_WL=-0.01, 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:307913 Archived-At: Ihor Radchenko writes: > The same update is happening when Emacs enters/exits let-binding or > switches between current cooperative threads. Which is actually quite a big issue. When Emacs descents into let binding and dynamic scope is active, it stores the existing variable value into a stack and sets the new value globally, into symbol's value slot. When ascending out of let, the existing value is discarded and the old value is set globally, recovered from the stack. And the cooperative threads simply manipulate the stack to store the thread-local values before thread yields and load the values from the next active stack. (though I did not look too close here) -- The conclusion so far: it will be difficult to support dynamic scope if we want things to run in parallel. We would need to implement some way to store symbol values in every thread (not necessarily all values, but at least the symbols changed by thread function). I can see several ways to approach this: 1. We can maintain a separate, sparse (just for changed variables) obarray inside threads, so that `intern' will point to thread-local symbol objects. 2. Force lexical scope inside threads, so that the values do not have to be stored in object value slots, but within per-thread lexical scope structure. This however, will not work when using things like `cl-letf' where Elisp code may want to temporarily set symbol function slots. 3. Store multiple value and function slots in symbol objects. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at