Eli Zaretskii <eliz@gnu.org> schrieb am Mo., 10. Okt. 2016 um 09:17 Uhr:

>
> > The reason I love Haskell for its STM concurrency (software transactional
> > memory) is that it makes certain classes of problems impossible to
> express. I
> > believe we would need a mechanism like that for Emacs Lisp, so no one
> ever has
> > to hunt down cyclic mutex locks, or reference counts, or why two
> operations
> > that should be atomic aren't. I'd rather have a single-threaded Emacs
> for a
> > quite a while longer before inviting these sorts problems into our lives.
>
> But we don't even know whether these problems are relevant to what Tom
> implemented in the concurrency branch.
>

We have lots of experience from other programming languages. Emacs isn't
that different (Elisp is mostly Python with a strange syntax), so we can
transfer experience to Emacs. Specifically, we don't have to reinvent
everything from scratch. There are a couple of high-level concurrency
models (STM, CSP) that are widely used in practice already.
Out of curiosity I've implemented Plan9/Go-style CSP based on libtask
(without OS threads) in Emacs with minimal changes, and most things seem to
work just fine.


>
> We've gone a long way since this issue was first brought up.  We've
> changed our sources in significant ways to support concurrency: all
> those BVAR and KVAR macros that are all around the C sources were
> introduced for that very purpose.  Likewise, the globals.h header
> file, and the fact that each variable exposed to Lisp is a member of
> some C struct -- all this was for supporting concurrency.  The code
> for this is written, debugged, and is only a little ways from being
> ready for prime time.


We still have tons of global mutable state, e.g. the buffer list.
Traditional OS-level multithreading is impossible with that amount of
global state.
On the other hand, non-parallel concurrency doesn't care about global state
(which can just be swapped out) at all.