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: Mon, 18 Sep 2023 21:30:17 +0800 Message-ID: <87h6nrwqvq.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35387"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Alan Mackenzie , 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 Mon Sep 18 15:31:38 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 1qiELh-00093a-Hb for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Sep 2023 15:31:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiEKl-0005rH-Q0; Mon, 18 Sep 2023 09:30:40 -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 1qiEKi-0005fl-Sc for emacs-devel@gnu.org; Mon, 18 Sep 2023 09:30:36 -0400 Original-Received: from sonic313-56.consmr.mail.ne1.yahoo.com ([66.163.185.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qiEKg-000418-83 for emacs-devel@gnu.org; Mon, 18 Sep 2023 09:30:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695043830; bh=oOnqFAr9DxhdZxJfqeElrTfkJEa7af+ZG+KGvhcpYfA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=R42Vu8nEewGP/UHR0RKlxaPzp2MImINKfSYhuYhh+wK3vFrwMZ04a4bDI+5INjFPATL9/vuIKbfXZ0y9k+M9006bw041KQwxoJ8uXDMWUPWeRoTpjxQ3829hWXBYldDvfNNgFI/jR0SPoRYkqP7B8+UaFhvPBB2yWkA/GOelJvgM9ZAlfwTp+yIW7t6kiavnQRkYuLoWSVhwENPr/eXJqz5m/QbjGmMdXiYFdnasRFpRKFostPgIl1N+ICaCQPobE4hGFIK4cOzidSoYwcxsPjAoq7+T0dEoVDZ2YAkU6Z2in0qnZzCNMoAaG7R2S1gD0dyq8BGg3Cv62LRDx0NCsQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1695043830; bh=SzHyU5G8BSezgi7azwMbMojJ91fo96TiZvPxr+LF8xq=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=pWDCQ6B/N8885vdS44ltLPMBJnNG+3O+uBau0gDuMdQ427IOzpnGklH7iL9VmBq5kOgE5X9rejD/BbtgxFc6W9Ydv5fYkTeLD6k23NrsHxGWhd4Sb9Gzk8w4Ct8ITldleIqEfLsiYGO0cE0HbsjT39C6r1WPugIfxDPvYTevJ1P/GeESD+VQtSu/7Z8DFyOctxl+DoGnw3Sb+7uPRT5RbeVobQEMGaeGgETrbmg6g26L74g7SLeVoNeIW9mv3PnAdZGPlGlgq5PKsaHOPsul0K1WZ5O51iiKqNkKxvWrCrVwKHjBz11BhGdRl/J7gkbEEixARSdzz2tA1Y1rrolhiA== X-YMail-OSG: zMXaw6AVM1mSOnFaYkKbSinPTfc9LhrR144v.rEcHjFrPR_NtFg_nmInF0lXa09 ARG53uFboCuJtsAQrrvhwTPs.XNz2totopVj6TU2tOTvgoAU7CrxJqbS8rPOtdKdEWqInG9e_YLv hj8LwmWixaTfnioHAya5PqTvsc9E9L4yj3SIrEQzreI1vm7YNvtbqBBskIGi8nqhwwXJSzgQkf_t oMyElQ43o0MN4WeOozxHz5CVXZAXukoDqnISW8o3Rl4mSD3jKmkdKgUcCSk0j7V1OQnouuIwDY5A sWSsQTZmACNGxGUH2AA57iIL8wf0k1gMpLZP8wiTvt2cGG08GqOrVY7QkMKqb6ZBWSsLEXgqBS0t jwONlnHqeH6Jyb3uXdBuSr784qcGO7CJFQTHHy8MAv5o7F12yd.6lgWnUW9Wo6t.psfRedOZDuQf 49A85vVnC.xf2CMg2vN7OwlPqK3phw6nfqTobqO4k01vdvGoLPEDjcqexfV_R7tcE9kPo4oz97HL 42a0Ae2M3MP0NRzH0Z6RGjt2IkyGz_KbRFJM8abfjwjRXAYi8IfAA60vL9DIEJXUmkOGX0PtpVR7 UxtsRvmnRbmPQ6Xtc_96eJNdXXI3rYkkp_tnUmLYv1iXO5avKT1vmK0AazzwAyv.n5YWeF3SYguu Xzz5pB00yGvVMP8MSW77ROd0zxtzls3Ex.D1Ztkd8pdHLojLnW548V149mirtzT3cvhl32UBkrZ3 oKY1qQw48FEE6ORYFF.YTICygl8iGMRmj_8Mk5RB3ItjVQp.95FHYm19GxG.627koY8qAOEDuRbZ r_Hv21qEvkeXiU.w_5uTr69RKyaJYLNRhlAWN.P547 X-Sonic-MF: X-Sonic-ID: 56e2a22d-a297-42c8-ba70-4b434b728997 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Mon, 18 Sep 2023 13:30:30 +0000 Original-Received: by hermes--production-sg3-55c667b499-jt2w5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c31cfd936b2c3f8040b6e65deac5802d; Mon, 18 Sep 2023 13:30:26 +0000 (UTC) In-Reply-To: <83v8c7elan.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Sep 2023 15:08:16 +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.185.31; envelope-from=luangruo@yahoo.com; helo=sonic313-56.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:310698 Archived-At: Eli Zaretskii writes: > I'm confused: suppose one thread modifies scroll-margin -- does that > affect the (global) redisplay? If it does, how will this "solve" the > problem? If it doesn't affect redisplay, how _can_ a thread change > scroll-margin in order to affect redisplay? It can't. Such adjustments must be performed from the main thread, as in all other modern GUI systems. In a prototype that I've been entertaining, this problem is simply left unsolved. Redisplay et all can only be called from the main thread; attempting to call functions that are not thread safe (presently all aside from those defined within alloc.c, that have been properly interlocked) signal an error. Objfwd variables consulted by redisplay are saved around redisplay_internal (and other similar functions), so that their values as perceived by redisplay can never change while it is in progress. This is no different from other GUI systems, where calling functions or setting variables that affect the UI outside the main thread is strictly forbidden, and either gives rise to a prompt crash or aborts with a failure indication. That multiple threads are incapable of sharing control over a functioning GUI system is a lesson taught with sweat and blood, and for it to be lost on us would be an awful shame. I suggest that people interested in a multi-threaded Emacs answer these two questions instead: - Is there a portable (in POSIX) method for reliably stopping a POSIX thread, with all callee-saved registers and register variables within leaf functions saved to the stack or some other area in memory? - How will finalizers, buffer modification hooks, symbol value watchers and the like be executed in response to garbage collection, buffer modification, or setting symbols in non-main threads? Instead of belaboring the subject of how different threads will somehow get away with coinciding calls to redisplay, or asynchronous modifications to its state. Because decades of research and experience from an innumerable number of individuals and organizations have produced an unequivocal answer: they won't. Just two cents from someone who actually _HAS_ a multi-processing Emacs in a quasi-functional state.