emacs-devel
[Top][All Lists]
Advanced

[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: Tue, 19 Sep 2023 15:38:33 +0300

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 19 Sep 2023 13:14:15 +0200
> 
> Eli Zaretskii wrote:
> 
> > We don't need to discuss all this because solutions for
> > thread synchronization exist for a long time. We even use
> > quite a few of them already: the Lisp threads we have in
> > Emacs now provide some of these synchronization primitives,
> > which are built on top of existing capabilities built into
> > the OS and existing thread libraries.
> >
> > So the problem is not how to lock and serialize access to
> > a variable in general, the problem is how to do this in
> > Emacs so that we won't need to lock everything.
> 
> Okay, excellent, but then why isn't it enough to just maintain
> a register of global variables and threads?
> 
> If a thread wants to use it, look in the register, is it
> available? If not, get in line. And when it becomes available,
> pop a thread in the line, if there is one, and start over?

You are describing what we already do, what every multithreading
program does.  You just call it "register", whereas its real name is
"mutex".

> Why do we have to lock everything just because we lock
> a single variable?

If we need to lock 99.99% of Emacs "single" variables, it is easier to
lock everything.  Faster, too.

Once again, you are looking at the wrong aspects of the problem.
These aspects are easily solvable, and we have even solved some of
them in the current Emacs.  The difficulties are elsewhere.



reply via email to

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