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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org
> Date: Wed, 20 Sep 2023 09:47:46 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (I suggest this because I feel that xdisp is a rabbit hole we may sink
> >> in instead of doing something more productive)
> >
> > I'm actually of the opposite opinion.  I think trying to parallelize
> > redisplay is a lower-hanging fruit, and if successful, it could bring
> > non-trivial gains to Emacs even if the rest remains single-threaded.
> 
> Without having Elisp async threads, what you suggest is only possible
> for the non-Elisp parts of the redisplay.

The display engine is written in C, not in Lisp.  What to do with the
few calls into Lisp we do in redisplay is an open question, but being
able to call Lisp from redisplay and being able to run several async
Lisp threads concurrently are two very different problems (although if
someone comes up with a solution for the latter, that would probably
solve the former as well).

> May you list which C-level parts of the redisplay are known to be slow?

I already did, in response to Dmitry's identical question.

> AFAIU, long-lines performance is largely problematic when running Elisp.

No, the slow parts are pure C.

> (Also, isn't it solved already?)

Not solved, but "bypassed".  The solution does have its disadvantages,
although we found them to be a much lesser evil than the original
problem.

> Another one you mentioned is displaying many frames. But isn't it
> optimized by the part of the code that delays redisplay of frames that
> are not visible? Or does Stefan (or anyone) tend to have so many
> _visible_ frames?

The latter.

> >> 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?
> >
> > xdisp.c has solutions for these two (and other similar) situations.
> > The problems have nothing to do with parallelism, they happen today
> > because we call Lisp at certain places in the display engine.
> 
> Yes, but now we know exactly in which segments of the code the geometry
> might change. And check for it in strategic places.

No, we don't.  We check the indications of this when a window or a
frame has been processed, that's all.

> In the case of asynchronous threads, the geometry may change any time
> (when another threads happens to run something that affects geometry),
> which is not accounted for by the current code.

The geometry cannot change by itself, because redisplay doesn't change
it.  It just detects the situation where the geometry must change, and
computes the variables that would determine the new geometry.  Then it
triggers resizing and recomputation of the geometry before retrying
redisplay.  The trigger to resize can be delivered to all redisplaying
threads, which will make them stop what they are doing, and then retry
after resize.

> >> > 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.
> >
> > There's more than one reason, that's true.  But it doesn't change the
> > fact that all those problems have to be resolved before we have
> > reasonably usable threads.
> 
> I disagree. Yes, _all_ the problems are to be solved eventually. But
> solving _some_ of the problems will already be an improvement. IMHO, it
> is not all-or-nothing; we can split the problem into several
> sub-problems and solve them one by one.

You've lost context, and effectively changed the subject, so now this
sub-thread is not useful anymore.  To recap, I was trying to explain
why the display aspects of any concurrency cannot be disregarded if we
want to have a workable solution that can be used in practice.

> >> 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).
> >
> > You forget that almost every Lisp program in Emacs either displays
> > something or affects stuff that affects redisplay.  It's easy to
> > forget, I know, because in Emacs redisplay "just happens" by some
> > magic.
> 
> I don't forget that. However, we do not have to make each and every
> thread _fully_ asynchronous. It is often enough to process the
> performance bottlenecks asynchronously. After that processing, we can go
> ahead and present the results synchronously to user.

This assumes the display is always in the end.  But that is a false
assumption in Emacs: there are progress messages, there are prompts
and requests for confirmation, there are display updates to show the
stuff processed so far, etc.

> Let me provide a more concrete example.
> Consider something as simple as grepping across project files.
> The process of grepping involves: (1) opening and searching many files;
> (2) presenting results to the user. Stage (1) does not really involve
> user interaction or redisplay and can greatly benefit from asynchronous
> threads - we can simply search multiple files at the same time. Then,
> even if stage (2) has to be synchronous, it does not matter - stage (1)
> is what takes most of the time and makes the user wait.

You describe an Emacs without async subprocesses -- this is how it
works on MSDOS, for example.  On more capable systems we display in
parallel with running Grep.

> > I'm not talking about async redisplay, I'm talking about the ability
> > of non-main threads to display something or do something that would
> > cause redisplay change the stuff on the glass.
> 
> Then, how will it be possible without first having async Elisp threads?

Async Lisp threads is a much harder problem to solve.  If we solve it,
this one will also be solved; but the opposite is not true.