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:14:49 +0300 Message-ID: <83fs3ackrq.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> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3012"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 16:15:55 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 1qibW5-0000Ur-Oh for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 16:15:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qibV5-0004rQ-79; Tue, 19 Sep 2023 10:14:51 -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 1qibV3-0004r3-MX for emacs-devel@gnu.org; Tue, 19 Sep 2023 10:14:49 -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 1qibV1-0000dv-Jf; Tue, 19 Sep 2023 10:14:47 -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=1XS1XNrEURFxvuOplK/TyG+9NkYj9HUeD5VsfvhkfpQ=; b=i9lmawENoMQv m99+6+dgNsdrXw5m8hQ0QzT0lGULSKDh01ZHuMhFYvMVi11znzUxWXjxF/ypR4j6ZP3Fo6FkEP1Dq W5JVp1WuLjKoeQ7XoMiXJAJbUFmKpjUABUVFfVl59V0C7oIvCeyCbhlseftpSmCqGJPy08wSf0YWa zVA+OH8Xgyf5yENA00JVtq3YnAEeCaXhaMpSWMUWeIe/gCbShGNnf0tbW8zQLQcOaLFYErNH3K9qi WOLZReIp3tqRkh6E6k0UR/URCioLWLQn5qPieUP944LlWKK4mrViiXR/5Rf40BM2mw1GKjhyDSq/s 4DfzJ1IjQN/eP4650Ye0QQ==; In-Reply-To: <877comnv4a.fsf@localhost> (message from Ihor Radchenko on Tue, 19 Sep 2023 13:35:49 +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:310770 Archived-At: > From: Ihor Radchenko > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Tue, 19 Sep 2023 13:35:49 +0000 > > Eli Zaretskii writes: > > >> > What is the global redisplay lock? > >> > >> I imagine that the implementation can involve global redisplay lock that > >> `redisplay' (or its internal functions) need to acquire before running. > > > > I thought you were describing the current implementation (where > > there's no lock). If you are describing some hypothetical future > > implementation, I don't see how we could usefully discuss this without > > much more details of that hypothetical design. > > This is very simple - I suggest to not touch xdisp.c as much as > possible, just make sure that it is interlocked. And focus on async > support in Elisp code. Once there is async support in Elisp code, we can > move further and look into xdisp. > > (I suggest this because I feel that xdisp is a rabbit hole we may sink > in instead of doing something more productive) I'm actually of the opposite opinion. I think trying to parallelize redisplay is a lower-hanging fruit, and if successful, it could bring non-trivial gains to Emacs even if the rest remains single-threaded. > >> Then, we had a misunderstanding. My point is exactly that xdisp.c relies > >> on global state _a lot_. And it will be non-trivial to change it. > > > > It doesn't _rely_ on the state, not on the level of the code. It > > _accesses_ the state as every other Lisp program does, since that's > > how Emacs accesses it everywhere. But there are no hidden assumptions > > that the variables used by xdisp.c are global. If each one of them > > will become buffer-local or thread-local, nothing significant will > > change in the xdisp.c code. All xdisp.c needs is to be able to access > > the value when needed. And since each window is processed separately, > > there's no assumption that something observed when displaying window > > W1 will necessarily hold when displaying window W2. > > I am particularly worried about scenarios when window geometry changes > by asynchronous threads. Or, say, face definitions. Imagine that it > happens at point when we are already drawing the now obsolete geometry > onto glass? xdisp.c has solutions for these two (and other similar) situations. The problems have nothing to do with parallelism, they happen today because we call Lisp at certain places in the display engine. > >> In my mind, it is easier to first solve the problem with generic Elisp > >> async threads and only then try to look into async redisplay. > > > > We tried that already, with the existing Lisp threads. One reason why > > those are almost never used is that the display issue was left > > unresolved. > > That might be one reason, but not the only reason. And certainly not the > most important reason for the use cases where I did try to use threads > myself. There's more than one reason, that's true. But it doesn't change the fact that all those problems have to be resolved before we have reasonably usable threads. > > ... Any real-life Lisp programs that tries to use threads > > bumps into this issue sooner or later. > > This is not true. Some Lisp programs? Yes. "Any"? No. Only toy Lisp programs can get away. > As we discussed previously, a number of Elisp programs can benefit from > async threads even when redisplay is not asynchronous - network queries > (gnus), text parsing (org-mode, slow LSP server communication, xml > processing). You forget that almost every Lisp program in Emacs either displays something or affects stuff that affects redisplay. It's easy to forget, I know, because in Emacs redisplay "just happens" by some magic. > To be clear, it would indeed be nice to have async redisplay. I'm not talking about async redisplay, I'm talking about the ability of non-main threads to display something or do something that would cause redisplay change the stuff on the glass.