Re: Questions about throw-on-input

[Arthur Miller]

Stefan Monnier <address@hidden> writes:

>> 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
I have a question, most for curiosity, it is is ok :-):

If you reversed the thought and started at "thread-end", could
you make every buffer be owned by some thread. Instead of buffer-first,
would it help to think thread-first? Thus Emacs process would become
more of a thread-scheduller, similar as some web browsers are using
separate process to render each webpage (in its own tab); I think Firfox
uses threads instead of processes. Maybe not the best way to use
multiprocessor cpus as of today, but certainly better then nothing at
all. Dont' know if it possible for Emacs and how underlaying "lisp
machine" is constructed. Maybe each thread could have it's own eval.
But then how would they communicate when they need, since Emacs
buffers often are used together in some way unlike webpages in a browser.

I hope you dont't mind interfering and my curiosity.