Re: Emacs design and architecture. How about copy-on-write?

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Nope. I consider that redisplay is always synchronous
>
> Synchronous to what?

Synchronous in a sense that no two `redisplay' calls can be executed in
parallel.

>> (because of global redisplay lock)
>
> What is the global redisplay lock?

I imagine that the implementation can involve global redisplay lock that
`redisplay' (or its internal functions) need to acquire before running.

>> If multiple threads trigger redisplay with different scroll-margin
>> values, it will be not different compared to the following example:
>
> I understand the problem, I'm asking what could or should be the
> possible solutions.

Sorry, I was not clear. My illustration was not to describe that there
is a problem. My illustration was to show that it is already possible to
run redisplay in various contexts (in the example - let-binding
contexts). Having multiple async threads call re-display with different
settings will be no different from what is already possible without
parallelism.

So, I claim that it is not a problem that should be solved (given that
we make sure that only a single redisplay call can run at a time).

>> 3. xdisp is relying on a number of global-only variables like
>>    `mode-line-compact', `show-trailing-whitespace', and similar.
>>    AFAIR, things like `show-trailing-whitespace' affect how the
>>    optimizations are applied when deciding which windows should be
>>    redisplayed and which should not. I suspect that logic related to
>>    optimizations may be very fragile with async execution.
>
> That's completely irrelevant to the issue at hand.  The fact that
> Emacs has a huge global state, and all of its code relies on that is a
> separate issue.  Here, I asked you in what sense is xdisp.c's code
> single-threaded; if your answer is "because of its reliance on global
> state", it means there's no separate problem of xdisp.c that is based
> on single thread.

Then, we had a misunderstanding. My point is exactly that xdisp.c relies
on global state _a lot_. And it will be non-trivial to change it.

In my mind, it is easier to first solve the problem with generic Elisp
async threads and only then try to look into async redisplay. Because
redisplay is already difficult to alter - untangling its global state
will be a huge task by itself.

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