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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > 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.
>
> I thought you were describing the current implementation (where
> there's no lock).  If you are describing some hypothetical future
> implementation, I don't see how we could usefully discuss this without
> much more details of that hypothetical design.

This is very simple - I suggest to not touch xdisp.c as much as
possible, just make sure that it is interlocked. And focus on async
support in Elisp code. Once there is async support in Elisp code, we can
move further and look into xdisp.

(I suggest this because I feel that xdisp is a rabbit hole we may sink
in instead of doing something more productive)

>> 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.
>
> It doesn't _rely_ on the state, not on the level of the code.  It
> _accesses_ the state as every other Lisp program does, since that's
> how Emacs accesses it everywhere.  But there are no hidden assumptions
> that the variables used by xdisp.c are global.  If each one of them
> will become buffer-local or thread-local, nothing significant will
> change in the xdisp.c code.  All xdisp.c needs is to be able to access
> the value when needed.  And since each window is processed separately,
> there's no assumption that something observed when displaying window
> W1 will necessarily hold when displaying window W2.

I am particularly worried about scenarios when window geometry changes
by asynchronous threads. Or, say, face definitions. Imagine that it
happens at point when we are already drawing the now obsolete geometry
onto glass?

IMHO, it is similar to the problem with GC - for synchronous code, it is
enough to sprinkle maybe_gc in strategic places in the code; for
asynchronous code, we have to somehow make sure that GC is not running
in parallel with another thread trying to allocate memory at the very
same moment.

>> 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.
>
> We tried that already, with the existing Lisp threads.  One reason why
> those are almost never used is that the display issue was left
> unresolved.

That might be one reason, but not the only reason. And certainly not the
most important reason for the use cases where I did try to use threads
myself.

> ... Any real-life Lisp programs that tries to use threads
> bumps into this issue sooner or later.

This is not true. Some Lisp programs? Yes. "Any"? No.
As we discussed previously, a number of Elisp programs can benefit from
async threads even when redisplay is not asynchronous - network queries
(gnus), text parsing (org-mode, slow LSP server communication, xml
processing).

To be clear, it would indeed be nice to have async redisplay. But before
having that we should have async Elisp code (otherwise we cannot run
Elisp from inside async redisplay). And I suggest to focus on this
first, necessary, step of getting async Elisp.

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