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 11:36:24 +0000 Message-ID: <87led2o0nb.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34222"; 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 13:36:25 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 1qiZ1k-0008eC-IZ for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 13:36:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiZ0k-0003vc-MU; Tue, 19 Sep 2023 07:35:22 -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 1qiZ0c-0003vA-Rb for emacs-devel@gnu.org; Tue, 19 Sep 2023 07:35:15 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qiZ0Z-0002qY-Ml for emacs-devel@gnu.org; Tue, 19 Sep 2023 07:35:14 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A43C0240105 for ; Tue, 19 Sep 2023 13:35:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695123309; bh=fwr7QoUZwAJNz5jy/0gA9ZFDJOvHKGW9d6wd83juvw0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=J40iOHVCTt5EeaFRjvPh6/1mskp1DoEJ5vJ5LIymIwDO4UcR3jY3FnyxWidBZea8w MpAIaCJ4YBItazzebl1m55z8G/1DQI+HY8pMFiWL7dU96/Dnw/xKEgVWNhZ/CXBEjT fJy6TdVNJGelnxDWz8w22UQNrHWZd1u1NEEyTNXSFeRmQZZ4j6hz+v++Dfnk7kZD2Y 4xyfm4arYE279KfILX1buv5JysMQRIiul09B7ppDgPM8DLPXg0oxdfuNPZo15hMFGP a9AzUulfSosN0VdSXK6Mw+n8Rc14hvCg8s7/PTgAyZKKPUWSPW+eFJldkwhqbEfKp9 +nwppcx07lpgA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rqfj86FpXz6tsb; Tue, 19 Sep 2023 13:35:08 +0200 (CEST) In-Reply-To: <83cyyfe5l8.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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:310748 Archived-At: 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. >> (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. >> If multiple threads trigger redisplay with different scroll-margin >> values, it will be not different compared to the following example: > > I understand the problem, I'm asking what could or should be the > possible solutions. Sorry, I was not clear. My illustration was not to describe that there is a problem. My illustration was to show that it is already possible to run redisplay in various contexts (in the example - let-binding contexts). Having multiple async threads call re-display with different settings will be no different from what is already possible without parallelism. So, I claim that it is not a problem that should be solved (given that we make sure that only a single redisplay call can run at a time). >> 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. 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. Because redisplay is already difficult to alter - untangling its global state will be a huge task by itself. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at