Eli Zaretskii <
address@hidden> 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.