Re: Questions about throw-on-input

[Stefan Monnier]

> An editor buffer is global mutable state.  Global mutable state is at
> the heart of GNU Emacs, and I disagree with the idea that we should
> try to get away from it.  That is a non-goal.

But the goal talked about here is concurrency.  Concurrency is not
incompatible with global state, but it's incompatible with global state
accessed from anywhere without any way to control it.

The problem, as I see it, is that we could imagine binding threads to
buffers such that a buffer can only be accessed by a single thread at
a time.

That would be reasonably easy to implement, I think, by putting a lock
on buffer objects (since there are fairly few ways to access a buffer:
you almost always have to make it current first).  But the buffer's
local variables can contain data such as hash-tables or cons-cells which
can be shared between various buffers, and that is a lot harder to
control because we don't want to put a lock on every cons cell.

Maybe we could have a notion of "buffer-local data/heap" and "global
read-only data/heap" or something like that and some way make sure that
a thread only operates of buffer-local data and global read-only data,
in which case it can indeed safely run concurrently with other Elisp
code operating in other buffers.


        Stefan