Re: Emacs Lisp's future

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]