From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Fri, 22 Sep 2023 18:22:41 +0200 Message-ID: <87ediqdvou.fsf@dataswamp.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> <8734zbyu6o.fsf@dataswamp.org> <835y46e8o9.fsf@gnu.org> <87zg1ixvnc.fsf@dataswamp.org> <87il86nxts.fsf@localhost> <87r0mux93s.fsf@dataswamp.org> <87r0mt88xv.fsf@localhost> <87msxedx5s.fsf@dataswamp.org> <878r8y6v6o.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7655"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:FZlPj19LgBTN3ScqDiSH3ZV8j8w= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 20:06:10 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 1qjkXY-0001it-GE for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 20:06:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjkWl-0004Fu-5j; Fri, 22 Sep 2023 14:05:19 -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 1qjivd-0007Bw-AH for emacs-devel@gnu.org; Fri, 22 Sep 2023 12:22:53 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjivb-00034u-KD for emacs-devel@gnu.org; Fri, 22 Sep 2023 12:22:53 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qjivZ-0006YC-3F for emacs-devel@gnu.org; Fri, 22 Sep 2023 18:22:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 22 Sep 2023 14:05:17 -0400 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:310985 Archived-At: Ihor Radchenko wrote: >>> Sorry, but I am completely lost. Cannot understand what >>> you are trying to propose. >> >> We can't build a new solution filled with exceptions so it >> won't break existing programs that were programmed for >> another solution. > > Eli's point is that the new concurrency framework must allow > the existing code to run without modifying it to fit > concurrency. Not necessarily fast (maybe with some > interlocking), but at least without breaking. > > Otherwise, making actual use of concurrency will require > rewriting a lot of Elisp, in addition to C-level support, > which is too much effort - we will have to fight many > non-obvious problems any time we want to call an "old" Elisp > function from purposely-written async thread. Multi-threaded concurrent access to global variables that will not break programs that were written using global variables with the then correct assumption no one else would touch them? But it is still possible, just the meaning of `setq', `let' etc will have to be changed so that they now are referred to the lock mechanism and also actually create local variables transparently which are subsequently used. -- underground experts united https://dataswamp.org/~incal