Re: save-excursion and multi-thread?

[Eli Zaretskii]

> From: Qiantan Hong <qhong@mit.edu>
> CC: "emacs-devel@gnu.org" <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.