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: Tue, 19 Sep 2023 17:36:57 +0300 Message-ID: <83bkdycjqu.fsf@gnu.org> References: <83edizjn0v.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40005"; 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 Tue Sep 19 16:37:27 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 1qibqx-000AHN-Ge for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 16:37:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qibqU-00062k-R9; Tue, 19 Sep 2023 10:36:58 -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 1qibqT-00062a-E1 for emacs-devel@gnu.org; Tue, 19 Sep 2023 10:36:57 -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 1qibqS-0007VU-82; Tue, 19 Sep 2023 10:36:56 -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=D8OpH0Oufq4sMHu5DUUPrq/B0+qZHzbIOXqb+RybXEY=; b=OHddtrEsmcMI 8wl0kBvq821dyZbZlTZeR9fmuU05W9ese+4qK02qZ7gRNNDkAbBxzOyi2jozu2iaPOIZg+BmhTJKi YBoAJoC/vx6jBoFvisBjMx+QIAwg1YYLirdisC+sm42/gAfE0lZ7KjyxiF1Z/+6574k/TdeDCHAkx 0EPyRPwyrnVAdWZg651o8OmNf/EXnfxerOfeNLDXUmC7q74yepG9pvTq379iD43quN95jq7EWm8kc /mIKZLYLQnKkk5OjCTgwmGrFVqnVYnP/pbJStFWDAVxGI8nv2nUOJhipYNPxXjSfkpeuEMuUDkn9o wDefZDmOU7bRlCeGSXARdg==; In-Reply-To: <87msxiuxqd.fsf@yahoo.com> (message from Po Lu on Tue, 19 Sep 2023 20:57:30 +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:310774 Archived-At: > From: Po Lu > Cc: Emanuel Berg , emacs-devel@gnu.org > Date: Tue, 19 Sep 2023 20:57:30 +0800 > > Eli Zaretskii writes: > > > If we need to lock 99.99% of Emacs "single" variables, it is easier to > > lock everything. Faster, too. > > Interlocking variables is not necessary. Extant buses guarantee that > word-sized (Lisp_Object) writes and reads from one CPU are always > coherently propagated to other processors. And otherwise, interlocking > every global variables would incur an extreme performance penalty; two > extra load-locked / store-conditional pairs (or interlocked > instructions) for each read or write at the minimum. 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.