Re: Emacs Lisp's future

[raman]

John Wiegley <address@hidden> writes:

1+ on this. 
>>>>>> 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.

--