Re: save-excursion and multi-thread?

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Sun, 26 Sep 2021 20:21:39 +0200
> 
> Qiantan Hong <qhong@mit.edu> writes:
> 
> > I tried
> > (make-thread
> >  (lambda ()
> >    (save-excursion (goto-char (point-min)) (sleep-for 1))))
> > In *scratch*.
> >
> > It seems that after the thread yields (because of sleep-for) it
> > doesn’t restore point position, and after 1 second cursor is reseted
> > to the original position,
> 
> The `sleep-for' is part of the thread's function, and also contained in
> the `save-excursion'.  So how could it be different?
> 
> > discarding any of my movements during this 1 second.
> >
> > Is this how save-excursion supposed to work?
> > It’s inconsistent with the behavior of special variable + dynamic
> > bindings, which works currently under multi-thread.
> 
> How are those related?
> 
> > What’s the supposed way to have “thread-local” movements?
> 
> The thing is, right now there are threads in emacs but no actual
> parallelism.  There's ever only one thread active and emacs switches
> between the existing threads at certain conditions, e.g., when one
> thread waits for input or a condition variable.  I guess another one
> might be `sleep-for' which would obviously make a lot of sense.
> 
> Oh, ok, I think now I got your question.  If `point' was a special
> variable, and let-bindings of special variables in a thread are local to
> this thread, then you would naturally have thread-local movements.
> 
> 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.

A thread can also be preempted by one of the following:

  . calls to thread primitives such as thread-yield
  . calls to primitives that read from processes, such as
    accept-process-output, and anything that calls these
  . becoming idle (which is a kind of "reading input", but maybe not
    everyone will realize that
  . waiting for X selections to do their thing