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 15:34:16 +0300 Message-ID: <83ttrqcpfb.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24102"; 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 14:35:22 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 1qiZwo-000606-1T for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 14:35:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiZvt-0006lT-TL; Tue, 19 Sep 2023 08:34:25 -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 1qiZvp-0006kR-UH for emacs-devel@gnu.org; Tue, 19 Sep 2023 08:34:22 -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 1qiZvn-0000Bd-3l; Tue, 19 Sep 2023 08:34:19 -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=7sZat5omnf7hM8PUAy4Q5uvrgaNrlaqdEcoN47aazCg=; b=lH6vLMhMCljn B+7Ybsr5Zatg+1jDoGp8yDFjlBQMvV5qkeegn1Pqq+Q/Whg8LYVjYYS7yvxzqpCgo7SKE1vqSyBW+ yiy/KSbHVOGlBFhn4Hqdy5e1PU51wZIsWhH1dkvK93ym1Nw7CMmmp3/rwf7ttCPZ/qsxzjXCdUNun qtJPcAXQDAG3dOiw5G/uzBwc7MW+FVtJPIHd3xzAreV482Z9zgkOv4RxGfeo7SdfnUYEkAv4H3p1A AQgQFpJeMwGsNncN4fItP9za/0FkNI1wV6V2q1CP07cq+KT8zThbm9OXj3kX1y5pHKD5T8vbutinz a0dvrIWDzmGJz9rC99/GPQ==; In-Reply-To: <87led2o0nb.fsf@localhost> (message from Ihor Radchenko on Tue, 19 Sep 2023 11:36:24 +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:310754 Archived-At: > From: Ihor Radchenko > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Tue, 19 Sep 2023 11:36:24 +0000 > > Eli Zaretskii writes: > > >> Nope. I consider that redisplay is always synchronous > > > > Synchronous to what? > > Synchronous in a sense that no two `redisplay' calls can be executed in > parallel. I think they can, if they display different buffers in different windows. > >> (because of global redisplay lock) > > > > 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. > >> 3. xdisp is relying on a number of global-only variables like > >> `mode-line-compact', `show-trailing-whitespace', and similar. > >> AFAIR, things like `show-trailing-whitespace' affect how the > >> optimizations are applied when deciding which windows should be > >> redisplayed and which should not. I suspect that logic related to > >> optimizations may be very fragile with async execution. > > > > That's completely irrelevant to the issue at hand. The fact that > > Emacs has a huge global state, and all of its code relies on that is a > > separate issue. Here, I asked you in what sense is xdisp.c's code > > single-threaded; if your answer is "because of its reliance on global > > state", it means there's no separate problem of xdisp.c that is based > > on single thread. > > 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. > 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. Any real-life Lisp programs that tries to use threads bumps into this issue sooner or later.