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: Emacs design and architecture. How about copy-on-write? Date: Wed, 20 Sep 2023 15:02:12 +0300 Message-ID: <83ttrpaw8r.fsf@gnu.org> References: <0518f65b-1dd1-6923-8497-da4d3aeac631@gutov.dev> <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> <87msxiuxqd.fsf@yahoo.com> <83bkdycjqu.fsf@gnu.org> <878r91vel8.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22338"; mail-complaints-to="usenet@ciao.gmane.io" Cc: incal@dataswamp.org, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 20 14:02:46 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 1qivuo-0005Yn-0o for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 14:02:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qivuG-0000rK-Ui; Wed, 20 Sep 2023 08:02:12 -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 1qivuD-0000qI-NY for emacs-devel@gnu.org; Wed, 20 Sep 2023 08:02:11 -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 1qivuC-00027b-Bt; Wed, 20 Sep 2023 08:02:08 -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=of//ncXcjVc1g2+awrHpKlW4QDOlTmHBzgLYZVmuM1k=; b=IIATiKhPAByH EhBKECQnlfjf4xf8I/paXJ6bHRuOdVnIF7jzLf/g9kn1dFsQ4vw8+hfcX6bcT8M1q1AGFBViI1Eks PBD2LNUIvT9d4RF/epoP/Wq1Y1nnnVMSnBDsbN+xUm01JvUG3DxBEk5qcZBhLrtN4K1DroZwSpVJB Fzsx4AlKkkbgVp4IPv8lx995m5maOPQs6kYq7OWUASxJWUw83u4aLxzoGzC3wd4Esmc2kNzOVE0G/ eIkjeoflNVBrCuNqZxUna1fq9GykYuSOlVfOOXzaMUORx29BajpRuqkbkPpNPhE3RGgJgg+7BxuH1 fLGqdfj3UAXmbzOQ8Zq86Q==; In-Reply-To: <878r91vel8.fsf@yahoo.com> (message from Po Lu on Wed, 20 Sep 2023 09:05:39 +0800) 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:310823 Archived-At: > From: Po Lu > Cc: incal@dataswamp.org, emacs-devel@gnu.org > Date: Wed, 20 Sep 2023 09:05:39 +0800 > > Eli Zaretskii writes: > > > That avoids garbled values where part of a value is from one thread, > > the other part from another thread. But it does nothing to protect > > the threads other than the one which changed the value from the > > "surprise" of having stuff change under its feet. Which is the main > > problem to solve, since Emacs code is written under the assumption > > that a variable in the global state doesn't change while some code > > runs that doesn't change that variable. That is why access to at > > least some things will have to be serialized -- to allow threads that > > access some part of the global state some level of control on what can > > and cannot change while they are doing their job. > > My solution (which I've put into practice in redisplay) is to save those > values before sensitive code is executed, and to refer to those saved > values within said code. That is _everyone's_ solution, not just yours. But it is not as easy in practice as it may sound. E.g., imagine a subroutine that is called by some higher-level functions, where both the callers and the subroutine need to access the same variable. When other threads are running, there's no longer a guarantee that both the caller and the callee will see the same value of that variable. If they must use the same value, you now need to pass that variable to the callee via its API, and this is not scalable when you have more than a couple, especially if the callee is not called directly, but via several intermediate callers.