emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: save-excursion and multi-thread?


From: Qiantan Hong
Subject: Re: save-excursion and multi-thread?
Date: Sun, 26 Sep 2021 19:09:42 +0000

> 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?
(defvar x 5)
(make-thread
 (lambda ()
   (let ((x 7))
     (sleep-for 1))))
x ;; => still 5 within this 1 second, by C-x C-e (which runs in main thread)

I think maybe the confusion is from different terminology to call special 
variable (in Common Lisp terms),
maybe you simply call it global variable or dynamic variable?

> 
>>> 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.
Isn’t all global/dynamic variable thread local, as in the example above?

> Right now, point is a field in the buffer data structure, so there's
> just one per buffer shared between all threads.  I think as long as your
> thread doesn't use `sit-for', `sleep-for', or reads input, you can be
> sure it won't be interrupted.  If it does, you cannot assume point is
> still there where your thread moved it.
I’m using thread exactly because my procedure need to wait and I don’t
want it to block the main thread.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]