From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Sun, 16 Jul 2023 14:58:11 +0000 Message-ID: <87y1jf29a4.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83y1jtgmbw.fsf@gnu.org> <87zg49xfke.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31096"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 16 16:59:08 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 1qL3DH-0007p0-23 for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jul 2023 16:59:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qL3CJ-0005wC-Gr; Sun, 16 Jul 2023 10:58:07 -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 1qL3CI-0005vw-BQ for emacs-devel@gnu.org; Sun, 16 Jul 2023 10:58:06 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qL3CF-0007O7-OU for emacs-devel@gnu.org; Sun, 16 Jul 2023 10:58:05 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B46CA240028 for ; Sun, 16 Jul 2023 16:57:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689519478; bh=TCHUg53jKoyRDSiv0TJCzcGdNwwGoNIvNXkWHJRbRE0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=h5/GifUw/AA1VD9oLFK2q6FKaAE7k8zFyUCvhkWLJr8f1vxKqmbjzcrnguK5DpKU2 ljXB8nGIRTR34xeSy+2d3usu7R0CqxixWGBVqo4gJmap2Iu1l+BU/XdVYutW3aBR1F NZsdNHvcQaK4N2f8wV2ytYwFzuDqofr36YlxOxhq/BMHDiqYOtNt34gC4Fsp/zcQAZ 4ik5l1JlmVjbSpPA7Ou1k/pN2pB/iQMUpVaT+I1ytgJyK4TfNBrz7IhX2X1za2LIuz AkrjyiqcYgJbz9Zcw/MIGnVyw2BTKbB4+5Vd/aamBYCnUsoc3ToxR6vYquaaSJRChq l/WtQ5z8YIjjQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3pHB0r26z9rxF; Sun, 16 Jul 2023 16:57:57 +0200 (CEST) In-Reply-To: <874jmd89us.fsf@localhost> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:307897 Archived-At: Ihor Radchenko writes: > 4. Buffer-local variables, defined in C have C variable equivalents that > are updated as Emacs changes current_buffer. > > AFAIU, their purpose is to make buffer-local variables and normal > Elisp variables uniformly accessible from C code - C code does not > need to worry about Vfoo being buffer-local or not, and just set it. > > This is not compatible with async threads that work with several buffers. > > I currently do not fully understand how defining C variables works in > DEFVAR_LISP. Currently, Emacs has a huge `globals' struct, where each record is a variable defined in Lisp. On C side, we have macros like #define Vdebug_on_error globals.f_Vdebug_on_error So, Vdebug_on_error can be used pretending that it is an ordinary variable. The location of stored Elisp value is thus fixed in memory. On Elisp side, the value cells of symbols point to special internal type, called "object forwarder". It arranges the actual symbol value to be a pointer to where the value is actually stored. For global variables the above scheme is easy. Tricky things start to happen when we make variable that has C reference buffer-local - the Vfoo C variable will always point to the same address in ~globals~, but that address can only represent a single value. So, Emacs has to keep updating ~globals~ every time we switch buffer: 1. An old value stored in ~globals~ should be recorded in to-be-switched-away buffer object. 2. ~globals~ is reassigned to load the value from new buffer. (the situation is a bit more complex, because updating is done lazily, only when the new buffer actually has a separate buffer-local binding for a given variable; but the basic scheme is as described). The same update is happening when Emacs enters/exits let-binding or switches between current cooperative threads. --- The easiest way to not break the current Emacs logic would be making ~globals~ thread-local. Then, the current code may remain intact, if we are content with global variables synchronized (or not) between threads manually (say, when a thread exits or when it calls something like `thread-synchronize-globals'). ~globals~ currently has 457 variables, which is \approx{} =sizeof (int) * 457= memory per thread. If memory is an issue, we may want to store only a list of actually changed variables in thread and change the current approach with Vfoo macro and have something like VSETfoo + VGETfoo. VSETfoo will always assign thread-local binding, adding it as necessary. VGETfoo will first check thread-local binding and reach out to global struct as fallback. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at