Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Mon, 10 Jul 2023 13:58:48 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> AFAIU, it is currently not possible to redisplay asynchronously.
> >
> > The main reason for that is that redisplay accesses the global state
> > in many places, and so it needs that global state to stay put.  Wed
> > already have trouble with keeping this so because we allow to run Lisp
> > from various hooks called by redisplay and via :eval in the mode line.
> > Quite a few bugs were caused by these, and had to be fixed by "fixing
> > up" the state, like making sure the selected frame/window were not
> > deleted under your feet etc.
> 
> Do you know which particular parts of the global state are necessary for
> redisplay? You mentioned current_frame and current_window. What else?

You are asking questions that would require me to do a lot of code
scanning and investigating to produce a full answer.  So please
forgive me if I can afford only some random examples that pop up in my
mind, not even close to the exhaustive list:

  . the window tree (redisplay traverses it depth-first)
  . point position of displayed buffers (needed to decide whether to
    scroll the window)
  . narrowing of each displayed buffer
  . text properties and overlays of each displayed buffer
  . which window is selected on each frame
  . window-start position of each window
  . variables affecting display: display-line-numbers,
    show-trailing-whitespace, line-spacing, auto-compression-mode,
    auto-hscroll-mode, mode-line-format, etc.

And that is just a few seconds of thinking, I'm sure I forget a lot of
others.