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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> So if point moves off the window, we will have a window that doesn't
> show point?

We will have a window whose point does not reflect its contents on the
display.  A supervening redisplay within the main thread will give due
consideration to its new value when it does transpire.

> Yes, but almost everything we do in Emacs has its purpose of affecting
> display, eventually.  Including process output we read and whatever
> computations we do.  Emacs is a real-time display editor, first and
> foremost, so this should not be a surprise.  The only notable
> exception from this rule is batch-style execution in a script.

These eventualities must take place within the main thread, that's all.

> How do you "transfer it to the main thread for display", exactly?

By setting a global variable that is subsequently read by the main
thread, modifying unread-command-events, and signaling a condition
variable that induces read_char to return the new value of
unread-command-events.

> And won't you want to display some kind of progress indicator while
> fetching? or show an error message if things fail?  Every Lisp program
> invokes gazillion low-level subroutines and primitives, and some of
> those feel free to ask the user questions, show messages, etc.  Even
> process.c shows messages, and modifying a file-visiting buffer might
> ask about supersession locks.  We cannot just forbid display from
> non-main threads, unless we are willing to rewrite most of the
> application code in Emacs, and many of the primitives as well.  The
> only solution that avoids the massive rewrite is to invent mechanisms
> that still allow non-main threads to communicate with users.

process.c can't be employed from non-main threads, as they are forbidden
from entering wait_reading_process_output.  Likewise for the file-lock
stuff, as it calls read_char.

My idea is that non-main threads will communicate with subprocesses and
read or write files through a different set of primitives, but they have
not been implemented.  The principle difficulty with the existing file
primitives is that they can call thread-unsafe Lisp; file name handlers
provided by TRAMP, for example.