From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Wed, 20 Sep 2023 21:50:59 +0300 Message-ID: <1736496a-f211-39d2-fa97-c3fad148cc39@gutov.dev> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33129"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Po Lu , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 20 20:53:03 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 1qj2Jo-0008IG-RY for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 20:53:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qj2I5-0003z8-F1; Wed, 20 Sep 2023 14:51:13 -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 1qj2I3-0003yt-DD for emacs-devel@gnu.org; Wed, 20 Sep 2023 14:51:11 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qj2I0-0006PV-7J; Wed, 20 Sep 2023 14:51:10 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E6CAB5C0061; Wed, 20 Sep 2023 14:51:04 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 20 Sep 2023 14:51:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1695235864; x=1695322264; bh=UFqjnY+uIEXo0hIfItU6BZ2Nb/PmnwKoZPa F7uCo2hQ=; b=kyiqj8Ob5Pph6E3CDIdJLx+dDRHGT0uLKa5Ic391tjUcFCXt4lK JT1FfihoYZz+sy5OPxrqC77mziW1qgZfTefkq5dj+YI2b+coiiLY8U6mkDViTa8l 25QcJcZJ1DJbdRafg6Jm5qoXXbJfbAYhnQGMEbjbTGGm3GVc8yVmawvinESL9tok 5VZGwti3D4tnkcNwXSIdAi1GLrcZEAeS79nusqDkPNyfoWEumH85pzJga/xs2VTm i3j8bUfM/gGEyc93f9BTBj+Gay3xDq5gvenFj7o2vflZBWnqm8bRXZmieu6aWFHI wvp1sw6mlG7ZCLSTnVTwPb+GhUXC+VgcPgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695235864; x=1695322264; bh=UFqjnY+uIEXo0hIfItU6BZ2Nb/PmnwKoZPa F7uCo2hQ=; b=nUgV6WvwphRphmg96eKWKd3rjkFA7QrPFa9zf023jcCdtwogQ2N r9W4KuVsn14ZtcIo143rYOrsP+em/VW9zpUxmCZs31jyQCrgp8mMuviBw58jBevb SNpkxDQbW3DCHSNsFtWCzsJj46db9g76tOwZU0Y/PgjeFvcs6FfB/sI/rVWkBLqM +wN7hSSWXxtHcEKkuBE+tptEOE5KhnsZ8i1T9MvxuKDMmGe//WEOfMVHujGyrzZy YPbH6I2zEHB942joWrr0ScRkXiIhPY1hWCXt1KZl3oXX+cQKPE5ONfsYiQNicVZ+ gEPRyrxV7I8YTTzJlJBy5LHeWddJQZ4tcwQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekfedgudefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Sep 2023 14:51:02 -0400 (EDT) Content-Language: en-US In-Reply-To: <87wmwlrqiq.fsf@yahoo.com> Received-SPF: pass client-ip=66.111.4.27; envelope-from=dmitry@gutov.dev; helo=out3-smtp.messagingengine.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 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, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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:310849 Archived-At: On 20/09/2023 15:13, Po Lu wrote: > 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. Could the "main thread" which works on the level of toolkits be/become a distinct notion from the "main Lisp thread"? >> 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. > >> 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. > > And there must be some other reason no other extant programs have > adopted such an approach. I would imagine (if we do get concurrent threads) that the UI thread might work like this: enumerate the visible buffers, "lock" each of the visible ones and then run redisplay on them. What's not-obvious is how to fit in the Lisp callbacks that are required in each of those by redisplay, especially, if some of the buffers are locked by non-default threads. At the moment (IIUC) this just looks like recursive calls because any redisplay is triggered by the main thread. And the above scheme would require running Lisp in a buffer which is locked by the thread different from the one that triggered redisplay. Though perhaps redisplay wouldn't be triggered by threads at all - not often, anyway. A thread could send a "request for redisplay" (if it needs to call something like 'redisplay' or 'posn-at-point'), at which point it might get suspended until the "display thread" gets to it. Then, if required, the thread runs any additional Lisp which is necessary to redisplay the current buffer. This could make those calls slower, but only experience would show by how much. If a Lisp thread doesn't really ask for redisplay, it could still be suspended by the "display thread" to do its thing. Could it run the necessary Lisp code on the suspended Lisp thread, though?