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: Emacs design and architecture. How about copy-on-write? Date: Fri, 22 Sep 2023 16:11:38 +0000 Message-ID: <87bkdu6vd1.fsf@localhost> References: <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <8734zbyu6o.fsf@dataswamp.org> <835y46e8o9.fsf@gnu.org> <87zg1ixvnc.fsf@dataswamp.org> <83sf7acp86.fsf@gnu.org> <87led2x8ao.fsf@dataswamp.org> <83r0mtaupr.fsf@gnu.org> <87pm2ae19p.fsf@dataswamp.org> <83lecy5hps.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="8205"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emanuel Berg , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 18:11:25 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 1qjikX-0001xU-5p for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 18:11:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjijp-0008L3-SL; Fri, 22 Sep 2023 12:10:41 -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 1qjijj-0008Jg-Vr for emacs-devel@gnu.org; Fri, 22 Sep 2023 12:10:36 -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 1qjijg-0000XZ-SL for emacs-devel@gnu.org; Fri, 22 Sep 2023 12:10:34 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9948F240028 for ; Fri, 22 Sep 2023 18:10:30 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RscgT5ftVz6tm4; Fri, 22 Sep 2023 18:10:29 +0200 (CEST) In-Reply-To: <83lecy5hps.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: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, 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 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:310977 Archived-At: Eli Zaretskii writes: > So one thread uses setq, releases the lock, then another thread comes, > takes the lock and changes the value of that variable, and when the > first thread uses the variable after that, it will have a value > different from the one the thread used in its setq? How can one write > a program under these conditions and know what it will do? IMHO, there should be a new API to lock global variables by async threads and/or set them. I can imagine 3 possible scenarios: 1. Thread does not rely upon global variable value being constant, only upon being able to set it. 2. Thread sets global variable value and uses it later, expecting the value to remain constant. 3. Thread let-binds global variable. (1) is easy - we just allow setting global value as we did in the past. (2) is trickier. We might need to provide a new API, so that thread can put a lock onto the variables it works with. Or, alternatively, we might keep the global values thread-local until the thread terminates - it will most closely resemble what the existing Elisp code expects. Then, an API for explicitly setting top-level values will be needed for new code that will be written with concurrency in mind. (3) is what Po Lu implemented in his current experimental code (AFAIU) - only set thread-local value with global variable is let-bound inside the thread. We know for sure that this value is neither reused by the concurrent threads nor needs to be kept outside the let-binding. BTW, Po Lu, what will happen when a thread spawns another async thread while some global variable is let-bound. Should the spawned thread somehow inherit the parent thread state? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at