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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> So a non-main thread cannot do anything that affects the display?
> Like move point in a buffer that is shown in some window?

This is possible, but moving point won't induce a redisplay of that
window.

> If non-main threads cannot change stuff that affects the display, what
> can those threads do? compute the 10ⁿ-th digit of π?

And other tasks like this, responsible for blocking Emacs.  Since most
of the time, Emacs is not blocked in redisplay, but reading process
output or performing difficult computations.

> Useful stuff in Emacs almost always affects the display, so if a
> non-main threads cannot do that, they will be useless.  Or what am I
> missing?

Consider the case of Gnus or Eglot: it will enable either of them to
fetch news or receive LSP output from a second thread, decode it, and
subsequently transfer it to the main thread for display.  Such expensive
processing is the reason people desire a multi-processing Emacs, because
it will facilitate efficiently running these operations in the
background and possibly on a different CPU.