[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Po Lu
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Tue, 19 Sep 2023 07:41:41 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]