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 15:08:16 +0300 Message-ID: <83v8c7elan.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14778"; 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 14:09:41 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 1qiD4N-0003XP-3k for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Sep 2023 14:09:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiD3J-0005oz-2r; Mon, 18 Sep 2023 08:08:34 -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 1qiD3F-0005oo-K0 for emacs-devel@gnu.org; Mon, 18 Sep 2023 08:08:29 -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 1qiD3D-0001CR-J5; Mon, 18 Sep 2023 08:08:27 -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=PqhRW8KYXhZeNAZh/tKIDWHfJlnwIo+Ms7mzmASSEqU=; b=ZMxLcHZC6jsh qqj7ujRK+J244qBVqNL4mun/6bFmHfSty4yQxjJY5qDrI9HHcP++kW1ArDTD6r3FzxXG6cpCMNnXQ hGrYaprw0qhYa74OUC/05464MVkNRDXy+kwC45Fnw6idK6j8huAADpSKYmbKsi8eFTMu62QX4HYKw pTSyTJponAPAkId3WNaSvJvQC8nJAMaImkvAhJOmkdKsfckksbc2e910QvBnQPh/hWw1dZ0uAPoz1 LDQuCUH8tveAwexPIWW1ldXo2Wxm79JOPQtrLE0B1AwQP25qAsFU3CjiJAXiydber4SqCGTtYvgj3 bJueqK7unxTpdUjBGA3v5A==; In-Reply-To: (message from Alan Mackenzie on Mon, 18 Sep 2023 11:38:56 +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:310696 Archived-At: > Date: Mon, 18 Sep 2023 11:38:56 +0000 > Cc: incal@dataswamp.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > > 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. After the thread terminates, and perhaps also while it still runs. E.g., consider some kind of progress-reporting facility. > 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. The danger is indeed that most of the variables will need to be protected by locks. If we cannot find a way of avoiding that, we are back at the current "only one thread at a time" model, and there's nothing to gain. > > > 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. I'm confused: suppose one thread modifies scroll-margin -- does that affect the (global) redisplay? If it does, how will this "solve" the problem? If it doesn't affect redisplay, how _can_ a thread change scroll-margin in order to affect redisplay? > > 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. It's one screen, but each window is redrawn separately (on GUI terminals). > If we get down into details, it might be worth having separate > threads for each frame, or even each window. I think this aspect of multithreading is so crucial that it must be considered from the get-go. Redisplay is one of the few places in Emacs where the assumption of global state is entrenched as deep as possible, so without some new ideas it will basically preclude multithreading. > > 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. I think the copy-on-write idea will work only for thread-local variables, and we already have those in the form of let-bindings. The important (and the hard) part of this is elsewhere.