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 13:53:10 +0300 Message-ID: <835y46e8o9.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9009"; 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 12:53:53 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 1qiYMb-0002At-4q for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 12:53:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiYLu-000666-V1; Tue, 19 Sep 2023 06:53:10 -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 1qiYLt-00065w-K5 for emacs-devel@gnu.org; Tue, 19 Sep 2023 06:53:09 -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 1qiYLs-0007H5-M3; Tue, 19 Sep 2023 06:53:08 -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=VPSMTzKQVEPKMnGVY9ri0TlrmrUYKKwaVRHRxtGrs7A=; b=deqfxtWc2AqZ hZMrxymrTgrTq5bMDZKouWG2l1z6cxbi9IzKAzT+YpKfkyakHCdljqSYMdB/PG367ub2ArJbseU2Z RhQFEtCydOGO3ka14T5SQMe8CRUuP6cRudl5JrgFak3r0YIC50I8g5MwqtXNWfk99fGwmiNr3NWGE DJgTLz7sZCP8Y0cxV/FaSlw1Gc6TPwD2hzlcvXv2Up8X15QvJ++gt+82fH5ILpJO9eIOSX7sBSdD8 4ZbiVm/hiJjeNoiQEWGG36nSDdByrIkOfAbaeWyGvDN5nhJ8d2lMON46wLxPrDRDAAeFuRyG0qs70 dtwrHDQRBUkigDbedvMZJQ==; In-Reply-To: <8734zbyu6o.fsf@dataswamp.org> (message from Emanuel Berg on Tue, 19 Sep 2023 00:48: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:310746 Archived-At: > From: Emanuel Berg > Date: Tue, 19 Sep 2023 00:48:15 +0200 > > Eli Zaretskii wrote: > > > it just means any such changes need to be communicated to > > other "redisplaying" threads, so that they also restart > > Instead of focusing on specific cases that one can imagine to > be problematic, why not look for a general policy what > should happen in the first place? The general policy is a solved problem, so there's no reason to consider it. > So, what does it mean for a thread to lock a global variable? > and set it? and use it? and then unlock it? > > What does it mean to that thread for the duration of its > execution? And what does it mean to another thread that is, or > isn't, doing or wanting to do the same thing, > possibly simultaneously? > > After that, one can think of how to setup a mechanism that > will safely uphold the model. > > So first thing, define what a thread T can do to a global > variable V. > > Second thing, what do we want to happen, when another > thread K does the same things in parallel, also to V? 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.