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: save-excursion and multi-thread? Date: Sun, 26 Sep 2021 21:53:51 +0300 Message-ID: <83y27jmam8.fsf@gnu.org> References: <5713E898-28B8-456C-992C-F0332FACA9FF@mit.edu> <8335prnqtq.fsf@gnu.org> <57C38454-3A17-47CC-A820-C7E63D8C2BBB@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23253"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 26 20:54:38 2021 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 1mUZIL-0005sC-Ip for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Sep 2021 20:54:37 +0200 Original-Received: from localhost ([::1]:49182 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUZIK-0007AT-3P for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Sep 2021 14:54:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUZHc-0006UD-Ia for emacs-devel@gnu.org; Sun, 26 Sep 2021 14:53:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57034) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUZHb-0004fm-V5; Sun, 26 Sep 2021 14:53:51 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4263 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUZHb-0004UK-Hm; Sun, 26 Sep 2021 14:53:51 -0400 In-Reply-To: <57C38454-3A17-47CC-A820-C7E63D8C2BBB@mit.edu> (message from Qiantan Hong on Sun, 26 Sep 2021 18:28:44 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:275528 Archived-At: > From: Qiantan Hong > CC: "emacs-devel@gnu.org" > Date: Sun, 26 Sep 2021 18:28:44 +0000 > > >> It’s inconsistent with the behavior of special variable + dynamic bindings, > >> which works currently under multi-thread. > > > > Inconsistent in what way? > > > >> What’s the supposed way to have “thread-local” movements? > > > > What do you mean by "thread-local" movements? Buffers are global, and > > each buffer has only one point. > Similar thing can be said with special variables — they’re global and has only one value. > But what “global” actually means is dynamic scope. > The values of special variables are associated with each dynamic scope > (while values of lexical variables are associated with lexical scope), > and each let binding attaches a value to the current dynamic scope. > (or really, the current continuation). > > Under multithread settings, each thread can have their own active dynamic scope (continuation), > therefore values of special variable doesn’t interfere. > I expects save-excursion to do the same. I'm sorry, I don't think I follow. I don't even understand what you mean by "special variables" or "active dynamic scope". Maybe you could explain it in some other way, perhaps with an example or two? > > by "thread-local" movements? > I mean some thread uses save-excursion around some operations involving navigating/editing > the buffer, and expecting to *not* affect buffer state outside the dynamic scope of such code block. > The current behavior makes practical sense under no circumstances, > because we don’t know what thread will be switched to and what it will be doing > after a thread yield. The Lisp threads in Emacs were not designed to support several threads making changes to the same buffer. On the contrary, the assumption was that each thread will have its own current buffer, which is why the current buffer is thread-local -- it can be different in each thread. There's very few variables that are thread-local, you can see them in thread.h. Most of the thread-local variables are there just to let threads run Lisp more or less independently, to handle non-local exits and errors independently, and support the thread-related primitives. Only a couple of them are exposed to Lisp in normal operations.