Re: Concurrency via isolated process/thread

[Ihor Radchenko]

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.

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

>> > 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?

>> 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.

It has XSYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED;

and the loop in set_buffer_internal_2 has
if (sym->u.s.redirect == SYMBOL_LOCALIZED

>> 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. So,
redisplay will have access to correct local values.

>> 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.

Basically, I propose async threads not to set buffer->pt in the buffer
object. They will operate using their own local excursion and
restriction.

>> > 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.

Fair.
Then, we can block if we need to store thread markers.

>> 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 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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>