From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Wed, 20 Sep 2023 09:05:39 +0800 Message-ID: <878r91vel8.fsf@yahoo.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18628"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 20 03:06:42 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 1qilft-0004f8-P3 for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 03:06:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qilfI-0006Xw-IQ; Tue, 19 Sep 2023 21:06: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 1qilfE-0006Xd-0d for emacs-devel@gnu.org; Tue, 19 Sep 2023 21:06:00 -0400 Original-Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qilfA-0001jn-Je for emacs-devel@gnu.org; Tue, 19 Sep 2023 21:05:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695171953; bh=WFIOI1rzbA3a50/MsIFsZOeyVSjzQmAQOPHjv3Gl1sA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=ffd7Vbft4zAYCSzXZ9z/yXVJ5q2n/tXSt0YVoFpUELJQw8rBE38mlK5o2JATtUWASw8acpOa/o8LFifcSmu7lA0A5AK5SOrEQT+KnBDb0D1tjcN+VR2D4FuNVt+x3kdKnpFUm8g2oumL3DQB3uyILNy72IXBgQfybIZexfWz5EYyUdHq97oSHTN0+tLA46/SIt97BNbdH0uOfbF0Dpe6bnRQrKv8NyAzrClcsDoUiA1eS2lqvMnyixVv+0B0XwPGM626Iv7WIRiTqmRnxeRmZcL28HYaoQee43/oNjZBrKRAUf7MuRsmGQqBosNRBEDrGuINqS3lh3rGMEymToA+Jw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695171953; bh=aYGe9ouAKUDDbY/GcyRcNGGDJQKP+tVPVpAjaLSN0qG=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=NNRWbpkrT3XhNWPCuy8zpDFDqufKNv4cKyd8CTuB8MJHZDERnqsw2zi0LtLswLRtX9Io3LTA3nEfqo662tmlAk0KWa+pLoHJQyflwRxyQiJkESqdD9QQrsWjsUccqX9XJ68X5hI5kBFvI0BtQBrA/8bUJlpB01krdqkgnHKpKOnckEE5exp/pU7PcBqA0kO36W9wUKxNsLESclP0qxdpQTlQMnlI9Y4JRaxxZHvT8Kgg7Xr6TJPDjlR2nezYHzuHhbWpqjM9H+AIBtf7zzflSZ8hFBPLKnz/hUtOTSpDAuB26nQ8wqzYqzjWLf7T/k9irLI1GarwPAFgpI9w/jLteA== X-YMail-OSG: _oZ6IJcVM1nJ.JmALogl0fvZws7fQ5eKJJglOvA4KMbZKbrIQTUFThxB6xz1ka6 14.1AqLm6AIwuSU8aq4WtwgY_O51n4FKwwNktGjwIGET3kdISPvOzpa56dBNfEiJtnEGW8dZVs81 b.cvfz_pUxW4LEwoaoDkMEypGW7AlUJQMyRKvn8buwe7Cl3AX2rkHPzA.avmc21Ji7HmyBlvR2Sh cX1CqsX80oW8PlKd0nBEXfwDcaaGZ0MrPxSSrXl09wSCxF1zeozWU3nrg2dtMFadkiiJ8LVksBhf rC6Uwhzrgz8Wker0zFCep27TTj7.axWoK5nTIg.js6w8NGUYq9IUrWREzKxIB445dtlH9F.UZByP zNj.3lUiKTusug1BGHGNX6pZQzGOLd.T0d3CdS6MSVdZpOKwDLt.dhlxrWdTdAjxvngUoNM4uOLN ITFWjzBOOJUXsqfTWRpxO9gciWLGIxyFs5Mn8JE8wWuKmEz7ajsJ9obCwPgaqwD7xyftC.fd__b9 WdOfiKA84SPmDgcjM_bF5SrHPok47u402ANPxj6vj.hTH4018YsypWJGORPjCPBQ2ZBQh7CwJE8s 5TZHMfXO9JWbw993AG6Pb7KBnteDpOvKk7nRZrxl0kCkoxfHhc5PyGih1n2x.KL3.bb0PbIDWZvV Fv8Nr1rYCgyIGJ9Fu6D.CqMQq8ZtOMZfk6A6uaFeEqdUhuE.C.gADczNmoVy5.u1R5750LxKV.Bx _0vKkQE2vGVhYmLanr6jqARwkEgCkfzeXICEaUAXkkiBLgCWgfDrPaJnoDGHT2QqiQb_IUeNOCP9 rsrnXCLr96pdsN13Jmt9EM1mQgQ_ucrnrd3RCtm41p X-Sonic-MF: X-Sonic-ID: 989821c6-80b8-49f3-8af2-92da740f4236 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Wed, 20 Sep 2023 01:05:53 +0000 Original-Received: by hermes--production-sg3-55c667b499-zxx5q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ca4e2dde6c6f459602865ff9b9c4c52; Wed, 20 Sep 2023 01:05:46 +0000 (UTC) In-Reply-To: <83bkdycjqu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Sep 2023 17:36:57 +0300") X-Mailer: WebService/1.1.21797 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.189.84; envelope-from=luangruo@yahoo.com; helo=sonic306-22.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:310800 Archived-At: 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. But right now I'm stymied by the representation of buffer-local variables (or rather the lack thereof in a multiprocessing Emacs), so I plan to give this subject a break for a week or two and revisit it later.