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: Mon, 18 Sep 2023 15:55:26 +0000 Message-ID: <87bkdzeas1.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33211"; 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 Mon Sep 18 17:54: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 1qiGaN-0008PU-82 for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Sep 2023 17:54:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiGZy-00071r-Un; Mon, 18 Sep 2023 11:54:30 -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 1qiGZx-0006zC-Ck for emacs-devel@gnu.org; Mon, 18 Sep 2023 11:54:29 -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 1qiGZu-0001uW-A9 for emacs-devel@gnu.org; Mon, 18 Sep 2023 11:54:29 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 634DD24002A for ; Mon, 18 Sep 2023 17:54:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695052456; bh=/Uve8yJc/z1keHa81iq1UzWMeBt0sK4t+Y9Qu84uPoI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=dLulUsaysNlSIGt3Hm03IJLywbJ9djMhfp446cE+eAKXOi4iVcOT5aLerXJ72u0B7 somTdYRXUkR93pkz5Veev8WmVJojSowIx+ioCpeDM6LaGDVhSfglgQ9W55K3zspOyv yijz57kULc9s9gAl6SBcA0ODD2FArrEsB+Z8GICppptLmHQS3D3lYmfvggqCKKnEmO a3nTQGr7DrRWucqdGmuEgbnlmvtO+jhAz0ZGG2A97FKZCLzq7i/o5+GpM/Cm8ERWvx L1QrWU30vH1AbrQwzPejc3PEjWQmDHY5/zFSKD3qdNpzvEr0KrgP3hvVRBBPInXt4/ wHwwTYx+y9hQg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rq8Vb2Rx5z9rxK; Mon, 18 Sep 2023 17:54:15 +0200 (CEST) In-Reply-To: <83ttrreeu0.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=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:310707 Archived-At: Eli Zaretskii writes: >> IMHO, the only sane way to utilize the existing redisplay is redisplay >> lock - only one thread can request redisplay at a time, using its >> thread-local state. > > So if one thread changes scroll-margin and triggers redisplay, then > another thread triggers redisplay with its (different value of > scroll-margin), the display will scroll or move point back? and then > forward again? and then back again? Nope. I consider that redisplay is always synchronous (because of global redisplay lock). If multiple threads trigger redisplay with different scroll-margin values, it will be not different compared to the following example: (let ((scroll-margin 500)) (redisplay)) <...> (redisplay) <...> (let ((scroll-margin 10)) (redisplay)) <...> A better illustration is probably (progn (let ((bidi-paragraph-direction 'right-to-left)) (redisplay)) (sleep-for 1) (redisplay) (sleep-for 1) (let ((bidi-paragraph-direction 'right-to-left)) (redisplay)) (sleep-for 1)) >> >> 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). >> >> Technically yes, but AFAIU the code is written assuming single-threaded >> execution. > > In what way does it assume single-threaded execution? We walk the > window tree of a frame and redisplay each leaf window in the tree, > that's all. Maybe I don't understand what you mean by "assuming > single-threaded execution". 1. xdisp assumes at its core logic that current_buffer is always a single buffer. And it affects, for example mode-line faces. 2. `display_mode_line' uses global temporary override by calling `push_kboard'. AFAIU, it is also relying on single-threaded code. 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. 4. There are complex interactions between window redisplay, mode lines, echo area, and toolbars. AFAIR, if some Elisp (or maybe C) code, recursively called during window redisplay, affects mode-line/toolbar height, xdisp restarts (sometimes, partially) the redisplay process. I expect issues when this interacts with async redisplay of individual windows. >> Decoupling redisplay of different windows would require significant >> non-trivial changes in xdisp.c > > In which part(s) of xdisp.c? Most of xdisp.c handles redisplay of a > single window. Yup, but see (4). I recall seeing a number of non-trivial `goto' calls where faces or window geometry are checked for changes and redisplay has to redo redisplay according to the changed values. When such geometry changes can also happen asynchronously, a number of places in the code that assumed fixed geometry and glyph matrix may be broken. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at