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: Tue, 19 Sep 2023 15:38:33 +0300 Message-ID: <83sf7acp86.fsf@gnu.org> 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> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5123"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Emanuel Berg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 14:39:12 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 1qia0W-00017h-3e for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 14:39:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiZzv-0001CN-SZ; Tue, 19 Sep 2023 08:38:36 -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 1qiZzu-0001Bp-Na for emacs-devel@gnu.org; Tue, 19 Sep 2023 08:38:34 -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 1qiZzr-0001JB-OO; Tue, 19 Sep 2023 08:38:31 -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=q7mhuKshNg3Y/OYTEgzK3ZdG2us9Vuh2NPVV4A9At9c=; b=K0rtkT4lY7ly 0dGgkzdqHLJAcYQf3NVEv0xiocgaPUKjbbWiseWkAwa/dvEYyAzWoILkdk6F/0Gsou+Hbls7ft08i h6IoPhJ7zB3rF9iD0qY/z/mukG+zmrjAAqPY5oUG04+Xrxj2uxdOh8ctk7Dzkf3QWtolKfoF8ugYc /stuT8WEvH58FNSiJe/CSLubqn8U7edtzlk26ojkPAopBsQiJi/2JP36Q5RVwdQRBZQjHYnqgS1D3 aKXqAL2kiLbwwsTBwtnPfTSfHx7s4VySq5/rR9Uqm0QlANtmpB5ut25ufZYNCl2ZsdyyFsBe1dXIF zPoRh7bRPMADVmrTnSal8g==; In-Reply-To: <87zg1ixvnc.fsf@dataswamp.org> (message from Emanuel Berg on Tue, 19 Sep 2023 13:14:15 +0200) 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:310756 Archived-At: > From: Emanuel Berg > Date: Tue, 19 Sep 2023 13:14:15 +0200 > > Eli Zaretskii wrote: > > > We don't need to discuss all this because solutions for > > thread synchronization exist for a long time. We even use > > quite a few of them already: the Lisp threads we have in > > Emacs now provide some of these synchronization primitives, > > which are built on top of existing capabilities built into > > the OS and existing thread libraries. > > > > So the problem is not how to lock and serialize access to > > a variable in general, the problem is how to do this in > > Emacs so that we won't need to lock everything. > > Okay, excellent, but then why isn't it enough to just maintain > a register of global variables and threads? > > If a thread wants to use it, look in the register, is it > available? If not, get in line. And when it becomes available, > pop a thread in the line, if there is one, and start over? You are describing what we already do, what every multithreading program does. You just call it "register", whereas its real name is "mutex". > Why do we have to lock everything just because we lock > a single variable? If we need to lock 99.99% of Emacs "single" variables, it is easier to lock everything. Faster, too. Once again, you are looking at the wrong aspects of the problem. These aspects are easily solvable, and we have even solved some of them in the current Emacs. The difficulties are elsewhere.