From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Sun, 17 Sep 2023 15:36:11 +0000 Message-ID: References: <43d642a8-d1b4-05ed-41e0-6e52d22df2d4@gutov.dev> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15069"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emanuel Berg , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 17 17:37:21 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 1qhtpp-0003iu-BP for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Sep 2023 17:37:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhtp2-0001tq-RK; Sun, 17 Sep 2023 11:36:33 -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 1qhtp0-0001t5-CT for emacs-devel@gnu.org; Sun, 17 Sep 2023 11:36:30 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhtoy-0007P9-Bw for emacs-devel@gnu.org; Sun, 17 Sep 2023 11:36:30 -0400 Original-Received: (qmail 50660 invoked by uid 3782); 17 Sep 2023 17:36:13 +0200 Original-Received: from acm.muc.de (p4fe152cb.dip0.t-ipconnect.de [79.225.82.203]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 17 Sep 2023 17:36:12 +0200 Original-Received: (qmail 10548 invoked by uid 1000); 17 Sep 2023 15:36:11 -0000 Content-Disposition: inline In-Reply-To: <83ttrsg9nx.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:310668 Archived-At: Hello, Eli. On Sun, Sep 17, 2023 at 17:24:18 +0300, Eli Zaretskii wrote: > > From: Emanuel Berg > > Date: Sun, 17 Sep 2023 14:16:57 +0200 [ .... ] > Mult-threading and global state are two opposites: an application that > wants to be multi-threaded should have as small a global state as > possible, and where it cannot be avoided, use locking to access global > state from different threads. > > Because if the whole thing has to be locked for each thread to > > access, it can be disputed if that is indeed any parallelism > > at all. It will be multi-threaded and multi-core alright, but > > not parallel execution unless one counts waiting for a shared > > resource to become available as a sensible passivity. > That's what we have with Lisp threads now: while one thread runs, all > the others are stopped by a global lock. > > So one would have to have a more fine-grained access to the > > resource - by splitting it up in pieces. That way one thread > > could access r_i while another accesses r_j and so on. > This was discussed here earlier, and ion is that it's easier said than > done. How about copy-on-write at a symbol value-cell/function-cell/property-list level? A value in a value-cell (etc.) would have an associated thread value, the thread which "owns" it. When thread1 gets cloned from thread0, it continues to use thread0's data state until it writes foo (e.g. by binding it). This would create a new value/thread pair, foo/thread1. Further writes of foo by thread1 would continue to access foo/thread1. Possibly, we could use just one owning thread for all the cells of a symbol. When a thread terminates, all its owned variables would become garbage, to be collected by our new garbage collector. ;-) Clearly, there would have to be some variables which would be thread-global, i.e. there would be a single value cell shared by all threads. There would also doubltless be other complications. The advantage of this approach, if it could be made to work, is that it doesn't try to fight the massive global state which is Emacs Lisp, instead accepting it and embracing it. What do you think? > > Again it would be interesting to hear of how other > > applications are doing it. > There's a separate mutex for each global data structure. -- Alan Mackenzie (Nuremberg, Germany).