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

[Eli Zaretskii]

> Date: Mon, 18 Sep 2023 11:38:56 +0000
> Cc: incal@dataswamp.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > When a thread terminates, all its owned variables would become garbage,
> > > to be collected by our new garbage collector.  ;-)
> 
> > You assume that whatever the thread does can be discarded as garbage?
> > That's definitely not true in general: most things we do in Emacs
> > should leave some trace behind.  It is not clear when and how this
> > would happen under your proposal.  E.g., imagine that a thread runs
> > Gnus fetching articles, and try to describe how this will work.
> 
> You mean that at the end of a thread, it will need to write results back
> to variables "owned" by the calling thread.  Yes.  Either these variables
> get marked as thread-global (not very attractive), or else we would need
> to mark specific variables as not to be copied on write.

After the thread terminates, and perhaps also while it still runs.
E.g., consider some kind of progress-reporting facility.

> With a thread fetching Gnus articles, there is the additional
> complication of having several such threads fetching from several servers
> at once.  Then access to the result variables would need to be locked, to
> prevent two threads overwriting eachother's results.  But this is so in
> any multithreading system, no matter how it's done.

The danger is indeed that most of the variables will need to be
protected by locks.  If we cannot find a way of avoiding that, we are
back at the current "only one thread at a time" model, and there's
nothing to gain.

> > > Clearly, there would have to be some variables which would be
> > > thread-global, i.e. there would be a single value cell shared by all
> > > threads.  There would also doubltless be other complications.
> 
> > "Some variables"?  Our problem is that their name is a legion.  E.g.,
> > what do you propose to do with variables and changes to buffer text
> > that affect the display?
> 
> I envisage each buffer being "owned" by a thread, possibly a special
> thread just controlling access to the buffer.  Variables like
> scroll-margin would be the thread's own binding of it.  There are a large
> number of dynamic variables in redisplay which, in the current Emacs,
> when bound by a thread would affect Emacs globally.  This c-o-w proposal
> would fix this problem.

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?

> > Or are you suggesting to have a separate redisplay for each thread?  Or
> > maybe you propose that each window has its own thread, complete with
> > its own display (and a separate thread for each frame)?
> 
> I don't think several redisplay threads would be a good idea - usually,
> there is just one screen Emacs is drawing on.

It's one screen, but each window is redrawn separately (on GUI
terminals).

> If we get down into details, it might be worth having separate
> threads for each frame, or even each window.

I think this aspect of multithreading is so crucial that it must be
considered from the get-go.  Redisplay is one of the few places in
Emacs where the assumption of global state is entrenched as deep as
possible, so without some new ideas it will basically preclude
multithreading.

> > I don't think you can avoid "fighting" it.  It's the elephant in the
> > room, and there's no way around that, because that global is the
> > backbone of the Emacs design, and all the Lisp programs and other
> > features implicitly assume it.
> 
> The c-o-w idea could steer around at least part of the globality.  I
> think it would be relatively simple to implement (hah!) and wouldn't have
> a large run-time cost, though of course there would be some.

I think the copy-on-write idea will work only for thread-local
variables, and we already have those in the form of let-bindings.  The
important (and the hard) part of this is elsewhere.