[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: Eli Zaretskii
Subject: Re: Emacs design and architecture. How about copy-on-write?
Date: Mon, 18 Sep 2023 15:08:16 +0300

> 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

> 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

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

reply via email to

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