Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 09 Jul 2023 09:57:20 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> Drastic changes as big as breaking the concept that indirect buffer has
> a single fixed parent are not likely.

Famous last words ;-)

> Of course, if there are breaking future changes on C level will need to
> account for concurrency.

Who will remember that we at some point "assumed" buffer->base_buffer
can change _only_ in make-indirect-buffer?

> >> > 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.
> 
> May you please point me to this documentation?

     In all other respects, the indirect buffer and its base buffer are
  completely separate.  They have different names, independent values of
  point, independent narrowing, independent markers and overlays (though
  inserting or deleting text in either buffer relocates the markers and
  overlays for both), independent major modes, and independent
  buffer-local variable bindings.

Or did you exclude overlays and their properties from the above?

> >> 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.
> 
> Another thread will have its own local set of Vfoo. When that thread
> switches to a buffer, it will update its local Vfoo values.

And what happens if that thread also changes Vfoo?

> So, redisplay will have access to correct local values.

No, it won't, because redisplay runs only in the main thread,
remember?  So it will not see changes to Vfoo done by other threads.
This could sometimes be good (e.g., if the changes are temporary), but
sometimes bad (if the changes are permanent).

> >> 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?
> 
> Async threads will not trigger redisplay. And they will have their own
> PT, BEGV, and ZV.

This goes back to the other sub-thread, where we discussed how to show
and prompt the user from non-main threads.  The conclusion was that
there is no good solution to that.  The best proposal, wait for the
main thread, would mean that stuff like stealth fontifications, which
currently run from timers, cannot be run from a thread.

> >> 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.
> 
> I kindly do not agree. It is not like a global lock. Yes, there will be
> a lot of blocking of individual Elisp objects. But it does not mean that
> everything will be locked.

I see no difference between locking everything and locking just 95%.

> I think there is a good way to tentatively check if everything will be
> locked or not - just check what will happen with consing. Consing
> appears to be one of the biggest bottlenecks that will basically cause
> global lock. If it can be demonstrated that consing is manageable, other
> things will pose less of an issue.

Consing is not even the tip of the iceberg.  The real bad problems are
elsewhere: in the global objects we access and modify.