From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Tue, 19 Sep 2023 13:35:49 +0000 Message-ID: <877comnv4a.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30346"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 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 Tue Sep 19 15:35:51 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 1qiatK-0007gE-OF for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 15:35:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiasQ-0007T2-Uc; Tue, 19 Sep 2023 09:34:54 -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 1qiasP-0007So-3E for emacs-devel@gnu.org; Tue, 19 Sep 2023 09:34:53 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qiasL-0006ZS-Fj for emacs-devel@gnu.org; Tue, 19 Sep 2023 09:34:52 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 0AB61240029 for ; Tue, 19 Sep 2023 15:34:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695130486; bh=Na7FbOQTfKiSH9w28h2grQTWWLi6G0fj5tdLj20vEBc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=bTCsDp5posHs2QxYdabsoR5V0nKnTsqaT6g+1UCfo9c8Sj4JcgCEaIMUx94jcTEyc KVK/g8DelYgbVwjMj+qxQYtReCXh22NICW6kF5lWoGhox1CH3HKavl3S2FviQx8fJ0 tzgjihB+hK0BPXWmggJ7K1bqWhaYxAr9X6KCQ7J32I467UkAhiKNpxpUxgQrViuCXq AdduUUA8ABbKNclz//7ywScAv71lVSTH1Qku+lvPeezPR/TEjYFgqHfgb63TLP2kwy TTSrH5iInu+NWu82HcLoeS2oGyFJC8DqDOlB/mj3dYR2oO26aGTaW5Fc7juXoSA6yW VRvj+t9SpafYA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RqjM90QKgz9rxB; Tue, 19 Sep 2023 15:34:44 +0200 (CEST) In-Reply-To: <83ttrqcpfb.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:310761 Archived-At: 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) >> 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? IMHO, it is similar to the problem with GC - for synchronous code, it is enough to sprinkle maybe_gc in strategic places in the code; for asynchronous code, we have to somehow make sure that GC is not running in parallel with another thread trying to allocate memory at the very same moment. >> 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. > ... 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. 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). To be clear, it would indeed be nice to have async redisplay. But before having that we should have async Elisp code (otherwise we cannot run Elisp from inside async redisplay). And I suggest to focus on this first, necessary, step of getting async Elisp. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at