Re: Emacs Lisp's future

From: John Wiegley Subject: Re: Emacs Lisp's future Date: Sun, 09 Oct 2016 19:59:09 -0700 User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (darwin)

>>>>> Eli Zaretskii <address@hidden> writes: > There's already a concurrency branch in the Emacs repository. It needs some > work before it could be merged to master, so if there are people here who > wants this badly enough, I suggest that they continue work almost done by > Tom Tromey, who developed that branch, instead of starting anew. I think it needs more than just a little work. I spoke to Tom on the phone last year, and we both agreed it's not a foregone conclusion that that branch represents the right way of approaching concurrency for an application like Emacs. In general, users don't want programmatic concurrency. What they want is for Emacs not to freeze up after they've asked it to do something. And there are other ways of achieving this end -- depending on the nature of the problem -- than making concurrency a first-class citizen, with the innumerable problems it brings. I fear we'd be debugging subtle interaction issues for the rest of our lives if we just merged Tom's branch in today. It implements a Java-style form of concurrency, dependent on mutexes and locking to achieve coherency, which is fiendishly difficult to get right, even if you confine its use to just a few small tasks. The hardest bug I ever debugged in my life was a concurrency bug; the second hardest wasn't even close (and thankfully, I didn't try to solve it at the same time). I'd much rather we re-examine the goals we want to achieve with concurrency, an then ask if there are other ways to get there besides, well, concurrency. For example, if we had a lightweight forking mechanism with transparent communication between sub-ordinate processes (think async.el, but in C and highly efficient), I think we could achieve what users want, without the downsides developers don't want. Even the popular web browsers are moving in this direction, since it gives a similar effect to threading, but without as many of the downsides; or take the popularity of the Actor model, used to reduce the coherency problem down to just mailboxes. 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. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

signature.asc

Description: PGP signature