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: Mon, 18 Sep 2023 13:30:15 +0300 Message-ID: <83h6nrg4eg.fsf@gnu.org> References: <43d642a8-d1b4-05ed-41e0-6e52d22df2d4@gutov.dev> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27263"; mail-complaints-to="usenet@ciao.gmane.io" Cc: incal@dataswamp.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 18 12:31:24 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 1qiBXF-0006sW-EN for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Sep 2023 12:31:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiBWN-0005Wi-8h; Mon, 18 Sep 2023 06:30:27 -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 1qiBWL-0005Vm-0b for emacs-devel@gnu.org; Mon, 18 Sep 2023 06:30:25 -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 1qiBWJ-0000rG-9f; Mon, 18 Sep 2023 06:30:23 -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=G9fJb1qAg1ORl7i9Yfnwn8vBqQUzqa7pOFPG86m5sDY=; b=MD2bkOAT2f38 Z4uGKVLdLwSVhiwNaz+rcdZ9Q28Yuzn8s7bV67MV+5IreV7DG2/DDS/MMlxkxqSbDPC9BtS0BNKVQ 4eAyC0W2I2tXiDD0tSnVEfSGA3j+r4OC0JwFDnAWIR/LTq0cgDd0aIi8vuiVYEp0KMRFafronMdgj 6nR7RSSSrS+JyTT78rccLF3Xrd/JJC68gZCzt/mZNoqoHmi6sKbnrOzBwEQ6ZWfc8N4QHVzbYtNhM PX1r35+6HEYOyZz+I4OJq5huewd8sKCKuHYInMlgeGageHVyFizXZG6KUhnSyBsyN1efGmQvc2na8 9gHhjeOuzInkxgWRslFNSQ==; In-Reply-To: (message from Alan Mackenzie on Sun, 17 Sep 2023 15:36:11 +0000) 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:310691 Archived-At: > Date: Sun, 17 Sep 2023 15:36:11 +0000 > Cc: Emanuel Berg , emacs-devel@gnu.org > From: Alan Mackenzie > > How about copy-on-write at a symbol > value-cell/function-cell/property-list level? > > A value in a value-cell (etc.) would have an associated thread value, the > thread which "owns" it. When thread1 gets cloned from thread0, it > continues to use thread0's data state until it writes foo (e.g. by > binding it). This would create a new value/thread pair, foo/thread1. > Further writes of foo by thread1 would continue to access foo/thread1. > > Possibly, we could use just one owning thread for all the cells of a > symbol. > > When a thread terminates, all its owned variables would become garbage, > to be collected by our new garbage collector. ;-) You assume that whatever the thread does can be discarded as garbage? That's definitely not true in general: most things we do in Emacs should leave some trace behind. It is not clear when and how this would happen under your proposal. E.g., imagine that a thread runs Gnus fetching articles, and try to describe how this will work. > Clearly, there would have to be some variables which would be > thread-global, i.e. there would be a single value cell shared by all > threads. There would also doubltless be other complications. "Some variables"? Our problem is that their name is a legion. E.g., what do you propose to do with variables and changes to buffer text that affect the display? Or are you suggesting to have a separate redisplay for each thread? Or maybe you propose that each window has its own thread, complete with its own display (and a separate thread for each frame)? These aspects need to be figured out if we want to discuss something like this seriously. > The advantage of this approach, if it could be made to work, is that it > doesn't try to fight the massive global state which is Emacs Lisp, > instead accepting it and embracing it. I don't think you can avoid "fighting" it. It's the elephant in the room, and there's no way around that, because that global is the backbone of the Emacs design, and all the Lisp programs and other features implicitly assume it.