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: Fri, 22 Sep 2023 15:34:52 +0300 Message-ID: <83cyya75eb.fsf@gnu.org> References: <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1683"; 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 Fri Sep 22 14:35:42 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 1qjfNm-0000DX-B7 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 14:35:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjfMv-0001IL-7d; Fri, 22 Sep 2023 08:34:49 -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 1qjfMr-0001Fm-2n for emacs-devel@gnu.org; Fri, 22 Sep 2023 08:34:45 -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 1qjfMp-0002fz-9t; Fri, 22 Sep 2023 08:34:43 -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=qXiACIjV1wpU4fHoDAarnPk3NC+DBt3RjtcrCtZr3hw=; b=ZpJAJCDA3e8t QOc6sbi/Mpvd8+t/py1IXNkTY3W2lyQWRq15IgjjOrrfxoIUFe53hZqXSKzSfiZIe8wH7SUe6ogde SagXK8tisLhGXS0DNZh0jWav3PCUcAVeB8TvdYJVVubGA8bHUC3FhnmYZyZSPpSCwQ4N59vBmGoP2 ip+tXnkPkeEZma6SJzkPRFa68XXfiSubQBoT7aOiPKEhWdABy0V811yIed3A3sKEonQK9EmOBiuxM CxuB+lFFMUl7NEamLKhIdLCIJKcPFs1tFVxx1VF8Fk6hva1vBUFPDi0ZhfDnAfihj1iacH7QWY/VP GpD5ZV6l5Bvab2SaID+mpw==; In-Reply-To: <87bkduxz3l.fsf@localhost> (message from Ihor Radchenko on Fri, 22 Sep 2023 10:48:46 +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:310954 Archived-At: > From: Ihor Radchenko > Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Fri, 22 Sep 2023 10:48:46 +0000 > > >> Again, not always. I do not think that the _initial_ goal should be > >> making every aspect of Elisp working asynchronously without > >> interlocking. We certainly want all Elisp to work in threads, possibly > >> with global lock. But if we get at least some part of useful Elisp to > >> run truly concurrently, it will already be a win. > > > > Not if we want to run the existing Lisp programs in threads with > > minimal or no changes. Because Lisp programs we have now require > > display and user interaction all the time, whether by themselves or by > > lower-level subroutines they call. > > Sure. _existing_. What I have in mind is programs specifically written > to take advantage of concurrency. Just to address common performance > bottlenecks. 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? > >> I think you misunderstood. I did not mean calling GNU grep. I meant > >> calling M-x grep - Elisp code searching across many Emacs buffers. It > >> would be useful if such code could run concurrently. > > > > It will be much more useful if it could also show the hits as it runs, > > instead of requiring the user to wait till it finishes. > > Maybe. But reducing the overall waiting time at the cost of not seeing > the progress is an OK compromise, IMHO. If the time is more than, say, a second or two, then no, such a compromise will not be liked. At least for Grep-style searches and other compile-like commands. > > I'm quite sure people who disregard the display when they are talking > > about concurrent Lisp threads are going to repeat the same mistake we > > made with the existing Lisp threads. We must learn from past > > experience if we want to succeed. > > 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.