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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand why only the main thread is allowed to do that.
> What is special in the main thread wrt redisplay that other threads
> are forbidden from doing that?  Would it be okay to have a separate
> non-main redisplay thread, for example? if not, why not?

Because toolkits forbid that.  One thread is customarily designated the
``main'' thread when the toolkit is initialized, after which any attempt
to invoke display routines from another thread induces a prompt abort.
This manifests itself most severely on NS and both GTK builds.

> They many times happen in the middle of processing, not just
> "eventually".

Then the text written to the glass will be inconsistent as long as
redisplay transpires while processing is still taking place.  Averting
such situations is not within our purview, but that of authors writing
Lisp code that exploits threads.

> How is this different from telling the main thread to stop, and then
> doing the display from the thread which triggered that?  IOW, why do
> we need to ask the main thread to actually display (and perform
> input), as opposed to just get out of the way for a short while?

Even with the toolkit problem notwithstanding, we would still have to
wait for the main thread to enter a section of code where it becomes
safe to yield to a second thread.  The main thread would then be hung
until any number of other threads complete redisplay, which IMNSHO
eliminates the raison d'etre for running multiple threads concurrently.

And there must be some other reason no other extant programs have
adopted such an approach.

> Why do they have to be a different set, not the same set which is made
> thread-aware?  E.g., if you don't want a primitive to do something
> when it runs in a non-main thread, it is easy to write a condition for
> that, and leave the rest of the code intact.

I'm not completely certain, given that the time I have dedicated to this
has mostly been committed to solving the buffer-local variable problem.

Let's bury this particular hatchet for the time being and revisit it
later, when I have the Lisp interpreter itself in a better shape.  OK?

Thanks.