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 17:46:49 +0300 Message-ID: <83h6noc36u.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> <83v8c5awj0.fsf@gnu.org> <87wmwlrqiq.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15140"; 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 16:47: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 1qiyUZ-0003eG-2O for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 16:47:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiyTk-0000tV-1N; Wed, 20 Sep 2023 10:47:00 -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 1qiyTi-0000tN-AQ for emacs-devel@gnu.org; Wed, 20 Sep 2023 10:46:58 -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 1qiyTg-0004J2-QV; Wed, 20 Sep 2023 10:46:56 -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=sz0tvYJbgwEOLAai83LRQ/oL2e0TsrVVPafEGJK1qEk=; b=SdH/SiMcGqgF POInVizHkELL3Cr7xqTXwyfxgvVA1l9wdaHrw+fmYO7TXBe+n6GMkw6hUGJp/MN6iNZoW8cgKo696 6Pd/Y76Sc8U4GFyk0ztXZizehfajhAlXKg3vMatBTA7xQGjnw3FzfFerH/a0+4fHKZmoL5lU0d6fd 3bI47K6PBDpd0tM2Pbxw1VSmdiyj+ItHSTpE8XDw1+7rTz2JjuUmEmH4+NCjhIbY3WHWnW9T7d6dd seEZQKEloL4EUUFFWx2KC6EkEMn4QUsIAaB0V2ArYmVCyv/Ci0EVZdZfGa+Bi1soztNp6l+nVAQ1X 6YfGZdnwBw2pPKBL+CKHTg==; In-Reply-To: <87wmwlrqiq.fsf@yahoo.com> (message from Po Lu on Wed, 20 Sep 2023 20:13:49 +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:310839 Archived-At: > From: Po Lu > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Wed, 20 Sep 2023 20:13:49 +0800 > > Eli Zaretskii writes: > > > 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? > > Because toolkits forbid that. One thread is customarily designated the > ``main'' thread when the toolkit is initialized, after which any attempt > to invoke display routines from another thread induces a prompt abort. > This manifests itself most severely on NS and both GTK builds. You are talking about the last stage of redisplay: delivering stuff to the glass. But xdisp.c is not about that, most of it has no interaction with the toolkit. > > They many times happen in the middle of processing, not just > > "eventually". > > Then the text written to the glass will be inconsistent as long as > redisplay transpires while processing is still taking place. Averting > such situations is not within our purview, but that of authors writing > Lisp code that exploits threads. So we drop on the floor the gobs of Lisp code written during the last 40 years, and tell the authors to rewrite everything from scratch under the new regime? > > 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? > > Even with the toolkit problem notwithstanding, we would still have to > wait for the main thread to enter a section of code where it becomes > safe to yield to a second thread. The main thread would then be hung > until any number of other threads complete redisplay, which IMNSHO > eliminates the raison d'etre for running multiple threads concurrently. The same will happen if only the main thread can display. If a non-main thread wants to prompt the user, it will have to wait until the main thread becomes available, prompts the user, and returns the response. Someone always has to wait when threads need to synchronize. There's no way around that. Doing this in the thread that needs to display/prompt is easier because the context and relevant variables don't need to be communicated to another thread.