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: Sat, 23 Sep 2023 14:23:18 +0300 Message-ID: <83r0mp3zh5.fsf@gnu.org> References: <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> <83fs3ackrq.fsf@gnu.org> <87ttrp89bx.fsf@localhost> <83led1aqnq.fsf@gnu.org> <87v8c3zun7.fsf@localhost> <83r0mr8w0j.fsf@gnu.org> <87bkduxz3l.fsf@localhost> <83cyya75eb.fsf@gnu.org> <877coh2lmd.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20645"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 23 13:23:58 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 1qk0ju-00059I-0S for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Sep 2023 13:23:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qk0j7-00036y-S9; Sat, 23 Sep 2023 07:23:09 -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 1qk0j6-00036b-Lb for emacs-devel@gnu.org; Sat, 23 Sep 2023 07:23:08 -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 1qk0j4-0004kB-H9; Sat, 23 Sep 2023 07:23:06 -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=1hdZzJhg4uzMjysVOUjYiXDUVUgvbiq6Yw6mhilxkkc=; b=BagjxMjJr/m2 nQNyDDpWOgYHExrlIU7mccQgbykyOW6mZyuKyeOJZKUzwqIPv6G6T3Ya6I10/GUQQSXxb9xQNebMi mZIgokUzl2m7VInvf5vnDN3A7t2SQC7BmaUW5p5Db6O82D/n0lKcNZ0YoEau1YXRlBubj4E2f71Z9 qapmxKOg18vVTdD9Y39bm0zwVWfeTM8boMVGuV80Vmz9UHaoRRPyYauwqFuwnFAI8Gnea/hLzMBi8 1GuGquxkBNaRnV2iJA7qPgt56xails9jW0shII4IQsXWT+aFu72IbivEZyj9N/rybTpZaZcdq3dUt cP33VqsODHt3utzkTGW/nQ==; In-Reply-To: <877coh2lmd.fsf@localhost> (message from Ihor Radchenko on Sat, 23 Sep 2023 11:07:54 +0000) 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:310996 Archived-At: > From: Ihor Radchenko > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Sat, 23 Sep 2023 11:07:54 +0000 > > Eli Zaretskii writes: > > > If we are talking about an Emacs where programs meant for threads will > > need to be written from scratch using special protocols and > > primitives, then all bets are off, and I'm not sure everything we > > discussed at such a great length lately is at all useful or even > > relevant. The idea was to allow existing Lisp programs run from > > threads with little or no changes, by just starting a thread which > > runs a function that is already written and debugged when running in > > the (single) main thread. If this is not what you have in mind, try > > first to see if users will be likely to switch to such an Emacs or use > > such threads, when they know they will need to drop everything and > > start from scratch. Who will want to write a "multithreaded Gnus" > > starting from scratch? > > Let me clarify. > I am not saying that existing Elisp code should not be allowed to run > from threads. It should. > > However, I think that it can be acceptable to leave certain things > interlocked - if async thread is querying, for example, user input or > redisplay, acquire a global (or input/redisplay) lock, and run that > portion of the thread synchronously. If this is done under the hood by the infrastructure, and the Lisp code doesn't have to be modified, this is, of course, fine. If the Lisp program that wants to interact with the user will need to do something special when it runs from a non-main thread, that is worse, but maybe still feasible. But what can we do about programs that call general-purpose subroutines, and those subroutines decide to prompt the user? And this is the problem which bothers me, because we are used to call many low-level subroutines without thinking about what that subroutine will do and whether it will want to prompt the user. As a trivial example, any function that modifies a file-visiting buffer could prompt the user if the file was meanwhile modified on disk. This prompt is completely out of control of any Lisp program which does something that modifies buffer text. How do we handle these cases? their name is a legion. > >> What about addressing the existing problems with cooperating Lisp > >> threads then? > > > > What about it? Patches are welcome, of course. Last time we > > discussed these issues, we were unable to find good ideas for solving > > them. Maybe we should try discussing them again. > > Are you referring to input discussion? Something else? I don't know what you mean by "input discussion", but I did already point you to the relevant discussion, so maybe that is it. > I think that it could be useful to document problems to be solved in > etc/TODO. Feel free. I don't think I can write something useful for that file, so I didn't.