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: Sat, 08 Jul 2023 11:55:34 +0000
> 
> >> And I still fail to see where base-buffer is _changed_. Is base buffer
> >> ever supposed to be changed?
> >
> > Another thread might change it while this thread examines it.
> 
> I was able to identify a single place in C code where buffer's base
> buffer is being set: in make-indirect-buffer, when the buffer is just
> created. So, it is safe to assume that buffer->base_buffer remain
> constant for any given live buffer. Unless I miss something.

C code can change.  It is not carved in stone.  Are we going to treat
the current state of the code as if it can never change?  That's
unwise.

> > Undo records changes in text properties and markers, and those are
> > different in the indirect buffers from the base buffers.  Does this
> > explain why we cannot simply point to the base buffer?
> 
> Are you sure? Text properties are certainly shared between indirect buffers.

That's not what the documentation says.

> >> > The C code accesses some buffer-local variables via Vfoo_bar C
> >> > variables.  Those need to be updated when the current buffer changes.
> >> 
> >> Now, when you explained this, it is also a big problem. Such C variables
> >> are a global state that needs to be kept up to date. Async will break
> >> the existing logic of these updates.
> >
> > Exactly.
> 
> I now looked a bit further, and what you are talking about are the
> variables defined via DEFVAR_PER_BUFFER.

Non necessarily.  Example: show-trailing-whitespace.

> If my understanding is correct, it should be safe to convert them into
> thread-local variables and update them within current thread when
> current_buffer (already thread-local) is altered.

It is only safe if no other thread will access the same buffer.  For
example, redisplay will be unable to show that buffer if it is visible
in some window, because its notion of the buffer-local values might be
inaccurate.

> >> > Oh, yes, they will: see fetch_buffer_markers, called by
> >> > set_buffer_internal_2.
> >> 
> >> Do you mean that in the existing cooperative Elisp threads, if one
> >> thread moves the point and yields to other thread, the other thread will
> >> be left with point in the same position (arbitrary, from the point of
> >> view of this other thread)?
> >
> > That's one problem, yes.  There are others.  Emacs Lisp uses point,
> > both explicitly and implicitly, all over the board.  It is unthinkable
> > that a thread will find point not in a place where it last moved it.
> 
> It is exactly what happens with current cooperative threads, AFAIK.

With the existing threads, this will never happen, because a thread
will never yield between moving point to some position and accessing
buffer text at that position.

> Will it make sense to convert PT, ZV, and BEGV into thread-local variables?

What do you expect redisplay to do when some thread moves point in a
way that it is no longer in the window?

> >> Is it buffer's marker list? I thought that you are referring to
> >> BUF_MARKERS, not to PT, BEGV, and ZV.
> >
> > Buffer's marker list are referenced in subroutines of
> > record_buffer_markers.
> 
> Do you mean record_buffer_markers->set_marker_both->attach_marker->
>   if (m->buffer != b)
>     {
>       unchain_marker (m);
>       m->buffer = b;
>       m->next = BUF_MARKERS (b);
>       BUF_MARKERS (b) = m;
>     }
> 
> But will this `if' ever trigger for PT, BEGV, and ZV?

I don't know!  You cannot possibly have code where you need to reason
about every single line whether something can or cannot happen there.
You need a relatively small set of basic assumptions that _always_
hold.  Anything more complex makes the task of developing and
maintaining this code an impossible job.

> Also, it looks reasonable to block BUF_MARKERS when we need to change
> BUF_MARKERS.

Sure.  Like I said: we'd need to lock everything.