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: Wed, 20 Sep 2023 14:56:03 +0300 Message-ID: <83v8c5awj0.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> <83ediuck9t.fsf@gnu.org> <87cyydverf.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29137"; 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 Wed Sep 20 13:56:48 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 1qivp1-0007Ms-Tf for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 13:56:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qivoQ-00072j-Sf; Wed, 20 Sep 2023 07:56:10 -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 1qivoP-00072V-LS for emacs-devel@gnu.org; Wed, 20 Sep 2023 07:56:09 -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 1qivoO-0000um-Kk; Wed, 20 Sep 2023 07:56:08 -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=51BtUH1O0Vzbv+LJcEwB29R9hY7egwlSOYySfQhtY7M=; b=gNSakcI2Zd55 9KXCq8ExAdBWTUOOxwPSFpIl1dOBLPajyZKv6c1Nlb9WE6KzivASSrW6uwyqZeF6RwMFLRjg6G8KM 3+sKp5BrKPdnv+BxZgEcu15s+tphyKe1ancOqpEd9d766mWtyV8PlBj2WI0vf4c3wlLvNO3rh2cm4 Q9mfotoLGkQRhw3o6w80GwShAC//92kmDyUBU42kdHdbhJg8hf494i6MsSzmf+mB2OLSQepYhrPDd 6U+tm0iPUgQ7lIjMOnWkkAlsQ8pchXU9ouWE/ioxriFqSTeeA1VVvkPDmBe4uQirr5hW5wdubeUGk yYlAyzN+mE/XVL1gTTBvIg==; In-Reply-To: <87cyydverf.fsf@yahoo.com> (message from Po Lu on Wed, 20 Sep 2023 09:01:56 +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:310821 Archived-At: > From: Po Lu > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Wed, 20 Sep 2023 09:01:56 +0800 > > Eli Zaretskii writes: > > > So if point moves off the window, we will have a window that doesn't > > show point? > > We will have a window whose point does not reflect its contents on the > display. A supervening redisplay within the main thread will give due > consideration to its new value when it does transpire. I don't understand why only the main thread is allowed to do that. What is special in the main thread wrt redisplay that other threads are forbidden from doing that? Would it be okay to have a separate non-main redisplay thread, for example? if not, why not? > > 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. > > These eventualities must take place within the main thread, that's all. They many times happen in the middle of processing, not just "eventually". > > How do you "transfer it to the main thread for display", exactly? > > By setting a global variable that is subsequently read by the main > thread, modifying unread-command-events, and signaling a condition > variable that induces read_char to return the new value of > unread-command-events. How is this different from telling the main thread to stop, and then doing the display from the thread which triggered that? IOW, why do we need to ask the main thread to actually display (and perform input), as opposed to just get out of the way for a short while? > > 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, 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. > > process.c can't be employed from non-main threads, as they are forbidden > from entering wait_reading_process_output. Likewise for the file-lock > stuff, as it calls read_char. > > My idea is that non-main threads will communicate with subprocesses and > read or write files through a different set of primitives, but they have > not been implemented. Why do they have to be a different set, not the same set which is made thread-aware? E.g., if you don't want a primitive to do something when it runs in a non-main thread, it is easy to write a condition for that, and leave the rest of the code intact. > The principle difficulty with the existing file primitives is that > they can call thread-unsafe Lisp; file name handlers provided by > TRAMP, for example. Tramp should be the least of our problems. The main problem with refusing to run Lisp from non-main threads is that Emacs will cease to be Emacs. The various Lisp hooks, calls into Lisp from C, and control on the internals exposed to Lisp are what makes Emacs the environment that is flexible and powerful to unprecedented degree. Take that away, and programs written for such an "Emacs" will be much less powerful and interesting, and certainly much less extensible.