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 18:51:43 +0300 Message-ID: <83lecy5hps.fsf@gnu.org> References: <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> <83sf7acp86.fsf@gnu.org> <87led2x8ao.fsf@dataswamp.org> <83r0mtaupr.fsf@gnu.org> <87pm2ae19p.fsf@dataswamp.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27616"; 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 Fri Sep 22 17:52:36 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 1qjiSI-0006tv-Pj for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 17:52:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjiRM-0007Gl-JT; Fri, 22 Sep 2023 11:51: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 1qjiRL-0007GL-DY for emacs-devel@gnu.org; Fri, 22 Sep 2023 11:51:35 -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 1qjiRK-0004Vb-H8; Fri, 22 Sep 2023 11:51:34 -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=qRFf+U6s2l6KZXDKWWudqYeJKmKyyP1nwRtVnhrPQk0=; b=S4oaDSeHdOaH n7TvNmiSwc5ynakhLk6hUA9a2eWaGu2DZtYCOunnes+I86GohdyQFaG01NYlJYCFqTgB03kdNhDIy GWOj25HhofNaOAKe0ZH13LqL9VIiQYkkpSO67PSf3j5FkoDzyuoKtSAXBasVw0USYnvItKvazTt37 RhxMnn5oSSwY8uEqTK370EeXluGt66XREJGwTKlURQT6kbEvkMUvHR9AAXjIHvngjj2le4icg4R/y PIiQWaxAB6DImwB7nncyurL9eVfJDe0essgjnRZ0gwjBD+Lb5NShJewPtdQvi8zxSXCdOtUpBooCF Gafwqpcrnr4musRnS4Dz7Q==; In-Reply-To: <87pm2ae19p.fsf@dataswamp.org> (message from Emanuel Berg on Fri, 22 Sep 2023 16:22:10 +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:310974 Archived-At: > From: Emanuel Berg > Date: Fri, 22 Sep 2023 16:22:10 +0200 > > There is no way around it, in order to prevent a race > condition any global variable must be locked before it's value > can be altered. > > So `setq', `setf' and any other setter of global variables > must first be refered to the locking mechanism where they > either acquire the lock, perform the write, and release the > lock; or, if the variable is already locked by some other > thread wanting to do the same thing, they must be queued so > they will get it in due time. So one thread uses setq, releases the lock, then another thread comes, takes the lock and changes the value of that variable, and when the first thread uses the variable after that, it will have a value different from the one the thread used in its setq? How can one write a program under these conditions and know what it will do?