Re: Concurrency via isolated process/thread

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Mon, 24 Jul 2023 13:02:26 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Would it be acceptable to convert buffer PT, BEGV, and ZV into
> >> thread-local for current cooperative threads?
> >
> > General note: it is very hard to have a serious discussion of this
> > kind of subject when the goals are not clearly announced, and there
> > are gaps of week or two between messages.  Discussing several separate
> > aspects of this makes this even harder to follow and respond in a
> > useful manner.
> 
> I was initially exploring what should be done allow async threads in
> Emacs. The discussion established several important global states in
> Emacs that must be changed. Then, I explored if those blockers are
> possible to solve. Now, I believe that all the blockers can be solved,
> if we accept to leave GC and redisplay synchronous.

So the goal is to eventually support true concurrency in Emacs?

> However, reducing the global state will not be easy and should better be
> done in steps. Ideally, steps that can be tested using the existing
> synchronous thread paradigm.

But the goal is concurrency? so these steps only make sense if the
concurrency is attainable via these measures?

> >> This way, when a thread yields and later continues executing, its point
> >> and restriction will not be changed.
> >
> > Why is the last sentence a worthy goal? what do you think will be the
> > advantage of that?
> 
> Consider a simple regexp search running in a thread:
> 
> (while (re-search-forward re nil t)
>   (do-useful-staff)
>   (thread-yield))
> 
> This search will fail if another thread ever moves point or changes
> restriction in the same buffer.

You are considering just the simplest scenario.  Usually, Lisp
programs in Emacs not only read text, they also write and delete it.
What if one thread makes changes to buffer text and another thread
then wants to access it using its state variables?  E.g., what do you
plan doing about the gap? will thread switch move the gap or
something? that alone is a performance killer.

> That's why I think that having threads store their own point and
> restriction is useful, even without considering that it will reduce the
> global state.

To be a step in the general direction of achieving concurrency, we
need some plan that will at least in principle allow concurrent
editing.  Even if "concurrent" here means that only one thread can
write to a buffer at a time, we still need to see how this will work
when other threads are unblocked once the writer thread is done
writing.  Can you describe how this will work, assuming we keep the
current design of buffer with a gap?