From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Mon, 18 Sep 2023 11:38:56 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22392"; mail-complaints-to="usenet@ciao.gmane.io" 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 Mon Sep 18 13:39:57 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 1qiCbd-0005bf-Ah for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Sep 2023 13:39:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiCan-0004Dq-6X; Mon, 18 Sep 2023 07:39:05 -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 1qiCal-0004DA-5K for emacs-devel@gnu.org; Mon, 18 Sep 2023 07:39:03 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qiCai-0002sA-Qy for emacs-devel@gnu.org; Mon, 18 Sep 2023 07:39:02 -0400 Original-Received: (qmail 35960 invoked by uid 3782); 18 Sep 2023 13:38:58 +0200 Original-Received: from acm.muc.de (pd953a7f6.dip0.t-ipconnect.de [217.83.167.246]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 18 Sep 2023 13:38:57 +0200 Original-Received: (qmail 7922 invoked by uid 1000); 18 Sep 2023 11:38:56 -0000 Content-Disposition: inline In-Reply-To: <83h6nrg4eg.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:310695 Archived-At: Hello, Eli. On Mon, Sep 18, 2023 at 13:30:15 +0300, Eli Zaretskii wrote: > > 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. You mean that at the end of a thread, it will need to write results back to variables "owned" by the calling thread. Yes. Either these variables get marked as thread-global (not very attractive), or else we would need to mark specific variables as not to be copied on write. With a thread fetching Gnus articles, there is the additional complication of having several such threads fetching from several servers at once. Then access to the result variables would need to be locked, to prevent two threads overwriting eachother's results. But this is so in any multithreading system, no matter how it's done. > > 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? I envisage each buffer being "owned" by a thread, possibly a special thread just controlling access to the buffer. Variables like scroll-margin would be the thread's own binding of it. There are a large number of dynamic variables in redisplay which, in the current Emacs, when bound by a thread would affect Emacs globally. This c-o-w proposal would fix this problem. > 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)? I don't think several redisplay threads would be a good idea - usually, there is just one screen Emacs is drawing on. If we get down into details, it might be worth having separate threads for each frame, or even each window. > These aspects need to be figured out if we want to discuss something > like this seriously. I'd like to emphasise that this copy-on-write idea is still just a vague idea which might help, not a worked out firm proposal. > > 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. The c-o-w idea could steer around at least part of the globality. I think it would be relatively simple to implement (hah!) and wouldn't have a large run-time cost, though of course there would be some. -- Alan Mackenzie (Nuremberg, Germany).