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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sun, Sep 17, 2023 at 17:24:18 +0300, Eli Zaretskii wrote:
> > From: Emanuel Berg <incal@dataswamp.org>
> > Date: Sun, 17 Sep 2023 14:16:57 +0200

[ .... ]

> Mult-threading and global state are two opposites: an application that
> wants to be multi-threaded should have as small a global state as
> possible, and where it cannot be avoided, use locking to access global
> state from different threads.

> > Because if the whole thing has to be locked for each thread to
> > access, it can be disputed if that is indeed any parallelism
> > at all. It will be multi-threaded and multi-core alright, but
> > not parallel execution unless one counts waiting for a shared
> > resource to become available as a sensible passivity.

> That's what we have with Lisp threads now: while one thread runs, all
> the others are stopped by a global lock.

> > So one would have to have a more fine-grained access to the
> > resource - by splitting it up in pieces. That way one thread
> > could access r_i while another accesses r_j and so on.

> This was discussed here earlier, and ion is that it's easier said than
> done.

How about copy-on-write at a symbol
value-cell/function-cell/property-list level?

A value in a value-cell (etc.) would have an associated thread value, the
thread which "owns" it.  When thread1 gets cloned from thread0, it
continues to use thread0's data state until it writes foo (e.g. by
binding it).  This would create a new value/thread pair, foo/thread1.
Further writes of foo by thread1 would continue to access foo/thread1.

Possibly, we could use just one owning thread for all the cells of a
symbol.

When a thread terminates, all its owned variables would become garbage,
to be collected by our new garbage collector.  ;-)

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.

The advantage of this approach, if it could be made to work, is that it
doesn't try to fight the massive global state which is Emacs Lisp,
instead accepting it and embracing it.

What do you think?

> > Again it would be interesting to hear of how other
> > applications are doing it.

> There's a separate mutex for each global data structure.

-- 
Alan Mackenzie (Nuremberg, Germany).