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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm confused: suppose one thread modifies scroll-margin -- does that
> affect the (global) redisplay?  If it does, how will this "solve" the
> problem?  If it doesn't affect redisplay, how _can_ a thread change
> scroll-margin in order to affect redisplay?

It can't.  Such adjustments must be performed from the main thread, as
in all other modern GUI systems.

In a prototype that I've been entertaining, this problem is simply left
unsolved.  Redisplay et all can only be called from the main thread;
attempting to call functions that are not thread safe (presently all
aside from those defined within alloc.c, that have been properly
interlocked) signal an error.  Objfwd variables consulted by redisplay
are saved around redisplay_internal (and other similar functions), so
that their values as perceived by redisplay can never change while it is
in progress.

This is no different from other GUI systems, where calling functions or
setting variables that affect the UI outside the main thread is strictly
forbidden, and either gives rise to a prompt crash or aborts with a
failure indication.  That multiple threads are incapable of sharing
control over a functioning GUI system is a lesson taught with sweat and
blood, and for it to be lost on us would be an awful shame.

I suggest that people interested in a multi-threaded Emacs answer these
two questions instead:

  - Is there a portable (in POSIX) method for reliably stopping a POSIX
    thread, with all callee-saved registers and register variables
    within leaf functions saved to the stack or some other area in
    memory?

  - How will finalizers, buffer modification hooks, symbol value
    watchers and the like be executed in response to garbage collection,
    buffer modification, or setting symbols in non-main threads?

Instead of belaboring the subject of how different threads will somehow
get away with coinciding calls to redisplay, or asynchronous
modifications to its state.  Because decades of research and experience
from an innumerable number of individuals and organizations have
produced an unequivocal answer: they won't.

Just two cents from someone who actually _HAS_ a multi-processing Emacs
in a quasi-functional state.