From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Fri, 22 Sep 2023 18:13:23 +0200 Message-ID: References: <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> <83lecy5hps.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4zyJPLaoaYvXLZb6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21290"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 18:14:04 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 1qjin6-0005O0-2z for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 18:14:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjimf-00023Q-Dh; Fri, 22 Sep 2023 12:13:37 -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 1qjima-00022y-Pd for emacs-devel@gnu.org; Fri, 22 Sep 2023 12:13:33 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjimV-0000yV-IY for emacs-devel@gnu.org; Fri, 22 Sep 2023 12:13:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=A2I0nz86MTogOl2mpIOe6GlTc8qtiBX0ZE5rrsZctRU=; b=GjekPFsktqtEPDbQjqhd52yaF2 EYyPyWZm3QeOInO6T2zLUleCHrB94xBCqpoLR2576GhrvT6MMDyhXEwBB4fs+akkzSccXsmAl1Ta+ dE8PRJDp7DquySZCY/cqduHDEHGbt3pmqdlxR/97dPZOplWV8ChN4WOXfb1sE2nGU8/mX1TYVKRnk Ur3uRDRh0zxpN+DfitmpkJwrMqSw98xy2N7CcqHaCfyZyM5scBLx9ZkX4l8CmEz+WsnnQzVN9H61d eJQX+kjebLN1fC6u7H/ZhJNpmdcP1nYyPjwq/D010YbcNoVBG8Nj32qFntaJLzW1srfH8GAQYxb0N xOtUehxQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1qjimR-0002zx-RA for emacs-devel@gnu.org; Fri, 22 Sep 2023 18:13:23 +0200 Content-Disposition: inline In-Reply-To: <83lecy5hps.fsf@gnu.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 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:310978 Archived-At: --4zyJPLaoaYvXLZb6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 22, 2023 at 06:51:43PM +0300, Eli Zaretskii wrote: > > From: Emanuel Berg > > Date: Fri, 22 Sep 2023 16:22:10 +0200 > >=20 > > 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. > >=20 > > 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. >=20 > 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? Nicer even. Imagine the compiler saying "oh, we have the value of this var already in this register!" (this is, after all, why compiled code is significantly faster). You can't do this anymore, because each global var is potentially volatile. Three quarter of your optimisation opportunities *poof* gone. Another: suppose you have three globals which have to be changed in sync. Do you lock around the whole change, although each var is locked in itself? Concurrency isn't easy. Most of the application has to "know", in a way. Cheers --=20 t --4zyJPLaoaYvXLZb6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZQ29EQAKCRAFyCz1etHa RjsaAJ9Xjxf00NPCxYbhYCg2soAAxT/4AwCdH4XxGAQDD2KRqmxuumYKXBBLzuE= =4jCt -----END PGP SIGNATURE----- --4zyJPLaoaYvXLZb6--