Re: Concurrency, again

[John Wiegley]

>>>>> "RS" == Richard Stallman <address@hidden> writes:

RS> (2) is a source of possible conflicts between various programs; I suspect
RS> that lots of bugs could result. Are such bugs why the "concurrency" branch
RS> is not ready?

RS> To limit concurrency to specially designated programs might make it easier
RS> to avoid those problems. Those programs could conceivably be written
RS> following certain special rules that avoid the bugs.

I'd like to note that the danger of such bugs really depends on how heavily a
given software package plays tricks with mutexes and yields.

For counter-example: Eshell today contains a function called `eshell-do-eval',
whose sole purpose is to evaluate a Lisp form up to a point where it would
otherwise block; save the current execution stack manually as a continuation
lambda in a global; then resume execution where it left off the next time
evaluation is attempted.

This code -- which is by far the most complex aspect of Eshell -- would simply
disappear once `thread-yield` became available, since that's exactly what
Eshell needs to do: yield execution until a condition is met, provided the
user isn't busily engaged doing something else.

So, for some use cases, threads as they've been proposed will simplify code
and reduce bugs, not make things worse. It depends on *how* it is used, what
damage it will do. I suppose the question then is: How much rope are we giving
new programmers to hang themselves with?

There have been other suggestions made to offer a better interface on top of
the threading primitives -- based on the actor model, or message passing, or
transactions, or futures, etc. -- such that none of the failure modes we fear
are possible through such an interface. This would restrict what users can do,
but might not restrict them so much that they can't achieve what is needed to
make Emacs less blocking.

So, even if we merged the concurrency branch today, this doesn't immediately
invite the hellhounds. It's just an implementation strategy, after all, for
allowing interleaved evaluation. I'm sure we can devise bulletproof ways to
make use of that functionality to achieve our end goal. If not, we revert.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2