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:25:34 +0300 Message-ID: <83ediuck9t.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> <87h6nrwqvq.fsf@yahoo.com> <83msxjed5c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20768"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 16:26:34 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 1qibgQ-00059E-7F for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 16:26:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qibff-0000CF-NQ; Tue, 19 Sep 2023 10:25:47 -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 1qibfe-0000C6-Ch for emacs-devel@gnu.org; Tue, 19 Sep 2023 10:25:46 -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 1qibfc-0003sy-Ez; Tue, 19 Sep 2023 10:25:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=71uV3lvH11M9sLgEc0hSlzqGguYTpXsT2wxO+80Vm8M=; b=Mfy2NA4Z6Ewl8jB28GrV 2HXz9r6TdNSuze7fhaCt7Tqo3k69SDcdCLEVaSCur1VkaCEPmXqK32jKB/5yB190EyzgLERu6zJvm p3I+iXR46osW5Cd3R252m+CxsrpdOd33q4axrRDQaBODLXYPSt+/Pmh3tmrMkl+dCq/JPtHyd2dH1 yTZtu/UfXeFVaymFPKr3Ev3sLZ3U0aZ/l2X8ZdNkM3Dtj/nyeQ+lkL18QsPSUyZylniNJJbYZCsSI ArvbEapL7GHRLmgO/d0JW50h5yxsPQtUVVMfQrWdXcUh4Sit6dwZUnxgVK9soUZM7F4lYv3+sXdVj SyiCJcGFRBO93w==; In-Reply-To: (message from Po Lu on Tue, 19 Sep 2023 07:41:41 +0800) 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:310771 Archived-At: > From: Po Lu > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Tue, 19 Sep 2023 07:41:41 +0800 > > Eli Zaretskii writes: > > > So a non-main thread cannot do anything that affects the display? > > Like move point in a buffer that is shown in some window? > > This is possible, but moving point won't induce a redisplay of that > window. So if point moves off the window, we will have a window that doesn't show point? > > If non-main threads cannot change stuff that affects the display, what > > can those threads do? compute the 10ⁿ-th digit of π? > > And other tasks like this, responsible for blocking Emacs. Since most > of the time, Emacs is not blocked in redisplay, but reading process > output or performing difficult computations. Yes, but almost everything we do in Emacs has its purpose of affecting display, eventually. Including process output we read and whatever computations we do. Emacs is a real-time display editor, first and foremost, so this should not be a surprise. The only notable exception from this rule is batch-style execution in a script. > > Useful stuff in Emacs almost always affects the display, so if a > > non-main threads cannot do that, they will be useless. Or what am I > > missing? > > Consider the case of Gnus or Eglot: it will enable either of them to > fetch news or receive LSP output from a second thread, decode it, and > subsequently transfer it to the main thread for display. How do you "transfer it to the main thread for display", exactly? And won't you want to display some kind of progress indicator while fetching? or show an error message if things fail? Every Lisp program invokes gazillion low-level subroutines and primitives, and some of those feel free to ask the user questions, show messages, etc. Even process.c shows messages,l and modifying a file-visiting buffer might ask about supersession locks. We cannot just forbid display from non-main threads, unless we are willing to rewrite most of the application code in Emacs, and many of the primitives as well. The only solution that avoids the massive rewrite is to invent mechanisms that still allow non-main threads to communicate with users. > Such expensive processing is the reason people desire a > multi-processing Emacs, because it will facilitate efficiently > running these operations in the background and possibly on a > different CPU. I know the theory. I'm talking about the details -- the devil is usually there.