From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Wed, 20 Sep 2023 20:13:49 +0800 Message-ID: <87wmwlrqiq.fsf@yahoo.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17972"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) 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 Wed Sep 20 14:15:18 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 1qiw6w-0004Sl-7T for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 14:15:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiw5r-000053-CZ; Wed, 20 Sep 2023 08:14:11 -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 1qiw5q-00004v-3I for emacs-devel@gnu.org; Wed, 20 Sep 2023 08:14:10 -0400 Original-Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qiw5n-0004jK-0D for emacs-devel@gnu.org; Wed, 20 Sep 2023 08:14:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695212044; bh=m8nnRnNbh8UUUikAw0HSRQJXzYc0KK728e17i4lf30w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=i1Nh38sAlCiTeT4osm+Pbuy/yarh5bp2JmxlId+JpCko38EmwPNUU8Diw/tOdV9tiQBv8GI2meagnRiQw7eCgVCv7qrgUZ51vDphgET1/02lO4DDwavvQepX65RyhBcV+R/IL26OkRWYMB2VqNPD0/uttO/atiagWFWXh83NnQBm73MDMpdbDDWd0wqmoMkQu4OOT2w1Tyb/zs3x7JycqzIDwRBbSBs749eHT8PGLHuXvHhlDyVQcdjqVf4jl99kQNN3g/uUeVelhRjZDYBujgha+6psspmIGk70GUs0vGsb7dmnBRx62W/sck5teAdMVA/gJmqwL35fJU4Tyimwag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695212044; bh=w67aBgLGb/szvvwS1cNxH6Dzpz/i/cUzb+EhORznQxq=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=AupOmJimAx2N5JhAfLEgdKB80qv4JgPewyX64PELhCrXrUpOHpcdEKCP2a9STB16n47kE4wLeRrjmYrLsWGoIVhV9iRXhOqwbq7S3Kn/JJYrvmV2lhBu2iRg2C6Ob9+qoO6TnDpZ4W22QlPyMdLy9q2LbjYzwogTQIuZNR38wX4OfHkgqpyvApD5VqVzkHx27iOdyQ9DG2uLhevP53YvJTUeGOUtLca3ubeiEhdFCCjzbepnJfgIRddjNs+z5jqi7OYBrW3wVfAo7pnk9wL2BT0E88ipv0hUNXI5o0M6Ot4vyMux5G9QNwh6jIoMAL2bD8lE7GgKeERatOHt1ggATQ== X-YMail-OSG: Vph29xEVM1mEPU.yyQpwDtpllUYrmXoNHDxcnyI_ecDUmAZYkQHsjgUn_3PWLAr ErA8nBMWXo7JYVXqsLk3PvjiwQ8hyqMXDG61sfpN8Em0cZ3NbC4oaApHgBP9tXlk2_r99Fo6Xe3z T1FMNfspyRjPFJWU5csBSkPwSRCSCkDj0kc9wX3CiIxWLxViij2jE3vXdHw1JjJJdyqVfwJGctuu ooW9eCFf86uRN8G1vijhfKNri37x12p4Rjy2XG0IXpZkbCqn3SdNYylOSvppoTuh70WDoLw9CxRi Tv33TV1BXedsIU3xXhKlrNCb_jk3ekrPQpr_Pm8qmHGfjCiKsEQsjnBvwu5217yWmAJ_yhD8uObd Y7cwcuB.6lRejCDxPlUTZJFPMQt6hu9bMkT4NEBASfNFzxIi3M.vPTKx3THdPsI5sbT3yXZLnefZ wFZE1K_GLACE_LIzJolP.Y3L.zD18zQCLR2wlD_CeBil7bfObRAM6zbf6JoK_6cGU0D4i_cU7Si7 fqAGAmL1Aau3aheovEM_w7vzWUdmJTryNNAx7Z48ySSlMt4XesHq4zCksuHA..lUAvNX6MLb4OaT YP2_Y11nE75axRQTuYGJ_xsfWTcE5CQzhWZLi6q2u79WzfGnkjiLA4j962mM77bUYnYARW9LzoUt 8jj6xhQneZFzH9FKH.0uJrPAOiIjEiclLsrIrBAkOsRAeuGRGktrgQF3vO77U3gLD.Zg1BIkxvqk RMZVc84VGrD5CiPVxeomDDFGdzfodHg34uIkg7lSamPe0qYBBaMSdn5yvSJEpUv0gd0MXtcGk6NB Z_l4Xb7M0qtZjj3CAZxsphjJLhoEzSL4TiwIDlLta1 X-Sonic-MF: X-Sonic-ID: 77ea9891-2ec9-417a-90b9-13f04681565e Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 20 Sep 2023 12:14:04 +0000 Original-Received: by hermes--production-sg3-55c667b499-fc69l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ac7d3c5dc854ccf5c09301244b46b09; Wed, 20 Sep 2023 12:13:58 +0000 (UTC) In-Reply-To: <83v8c5awj0.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 Sep 2023 14:56:03 +0300") X-Mailer: WebService/1.1.21797 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.190.146; envelope-from=luangruo@yahoo.com; helo=sonic315-20.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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:310828 Archived-At: 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. > 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. > 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. I'm not completely certain, given that the time I have dedicated to this has mostly been committed to solving the buffer-local variable problem. Let's bury this particular hatchet for the time being and revisit it later, when I have the Lisp interpreter itself in a better shape. OK? Thanks.