From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Fri, 22 Sep 2023 02:43:46 +0300 Message-ID: References: <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <8734zbyu6o.fsf@dataswamp.org> <835y46e8o9.fsf@gnu.org> <87zg1ixvnc.fsf@dataswamp.org> <87il86nxts.fsf@localhost> <87o7hyx8h2.fsf@dataswamp.org> <87o7hx88ry.fsf@localhost> <87a5thta90.fsf@yahoo.com> <87led1865h.fsf@localhost> <875y45t7yo.fsf@yahoo.com> <874jjprmq2.fsf@yahoo.com> <83a5tgc03s.fsf@gnu.org> <87zg1gqr8q.fsf@yahoo.com> <83msxg9eb9.fsf@gnu.org> <87msxgq8rn.fsf@yahoo.com> <83jzsk9c5l.fsf@gnu.org> <87msxf2abp.fsf@localhost> <83h6nnalu5.fsf@gnu.org> <87y1gzzvec.fsf@localhost> <87zg1fpwz7.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19505"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Po Lu , Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 01:44:47 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 1qjTLh-0004tc-A3 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 01:44:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjTKu-00040I-Vb; Thu, 21 Sep 2023 19:43:56 -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 1qjTKs-0003zz-5u for emacs-devel@gnu.org; Thu, 21 Sep 2023 19:43:54 -0400 Original-Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjTKp-0006Jc-T2; Thu, 21 Sep 2023 19:43:53 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 698C03200805; Thu, 21 Sep 2023 19:43:49 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 21 Sep 2023 19:43:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695339828; x=1695426228; bh=SjALRHKV8mZLWUYeK41bkRhJSZmivx2jDfw 2LOrI7yE=; b=KoZgMa46QOzVhIvdI5BF+/6euIb4Esypfwc2x4UMlIOyu/kpxm/ Hv/4QbDOAtOmA/qGu00awveEJwiQUDxfqRhUJJ5VQItPTO84q5Qc7oMNSB6CfIqK nL4bciN22aU/71M7mf+s1ZvnBxe+e+WlIRoob6mcxWuEEYDzTbvS6jVgMa7x2SFc 1ubHRpE02Zvtz43VVTLv4+C27QXChxXAJHFG5yCLUoo1LDBsy3+VM/t45zBcrIHW B6dO7ySoMwkLWInyGbDF1eUZBjkrOig7fA5ehm3LkLtLEC3xCNYFVkzZMMYO3mw9 HR+cfZntWbsr3urJvmr/oPq5XuUPIo6vudQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695339828; x=1695426228; bh=SjALRHKV8mZLWUYeK41bkRhJSZmivx2jDfw 2LOrI7yE=; b=ab9Pzgg+mI4mcRV4vF83P60A84i0YPyMdZnc0ULf8n6MtMtKDcg czExsZIz/roFDSP7bfpNHFvI30S1MaUh4dVcPZb6+TkLZQSUGDTtgjFlovoJTxJM ybQu/WhAz8DkmzhRrJ+gXi0BeFE4310B5dvbsQ46kVn+jozQ94xBnbAyhJMdN9nK sBIk0p3zTOcjmjRZfPbwcz2mVJjaFxx3Jr/dM2gNOK7SRd5sNcikCZlCTkEyLcHt M5mNME8Te7LKCMNTPTrhlRvG7A/fun5aGegD+XQiews9jFNcVxca/v424T0YmCPV UYuDhKxNH18+UQzDcoWRF2MOZASDy/xVizw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekjedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeevtdefjefhffdugefghfevjeetueehfeejueegvefggeeijeetudffledu jedvnecuffhomhgrihhnpegtlhhojhhurhgvrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Sep 2023 19:43:47 -0400 (EDT) Content-Language: en-US In-Reply-To: <87zg1fpwz7.fsf@yahoo.com> Received-SPF: pass client-ip=64.147.123.25; envelope-from=dmitry@gutov.dev; helo=wout2-smtp.messagingengine.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 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, NICE_REPLY_A=-1.473, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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:310935 Archived-At: On 21/09/2023 14:49, Po Lu wrote: > Ihor Radchenko writes: > >> As I understand his previous explanations, global variable values are >> stored per-thread, if they were changed by that thread at some point. >> For C-defined globals, the Vname instances are re-defined to >> point to thread-local "globals" struct. >> >> I do not recall Po Lu providing the details on how the thread-local >> variables are stored. > Non-forwarded thread-local bindings are saved within a separate > association list in Lisp_Symbol, where each element ties a thread to its > local binding. do_specbind and do_one_specbind manage this association > list by introducing new associations. set_internal and > find_symbol_value search within this association list for a pair > matching the current thread, and set or return its cdr respectively if > it is present. > > Within lispfwds, the pointer to the field itself is replaced with an > offset to a field within struct thread_state which is set to a pointer > to the matching field in `globals' or one of its local bindings. > > Whenever a forwarded variable is specbound for the first time in a given > thread, the designated field within that thread's state is set to a > pointer into thread local storage, and once unbound, restored to its > initial value within globals. That reminds me of Clojure's threads and dynamic vars' semantics: https://clojure.org/about/concurrent_programming By default Vars are static, but per-thread bindings for Vars defined with metadata mark them as dynamic. Dynamic vars are also mutable references to objects. They have a (thread-shared) root binding which can be established by def, and can be set using *set!*, but only if they have been bound to a new storage location thread-locally using binding. Those bindings and any subsequent modifications to those bindings will only be seen within the thread by code in the dynamic scope of the binding block. Nested bindings obey a stack protocol and unwind as control exits the binding block.