[E-Lang] Re: Why Not Coroutines? (was: Deadlock-free [was what is good about E?])

[Mark S. Miller]

At 08:10 PM Wednesday 7/18/01, zooko@zooko.com wrote:
>The first reason, as you described, is that pre-emptive multithreading
>prevents me, when reading a sequence of source code, from using valuable
>assumptions about how all of the state remains unchanged during the execution
>of this sequence except for changes caused by the code I am looking at.
>
>The second reason is deadlock.
>
>The third reason is that bugs caused by the first two reasons are almost always
>non-reproduceable and rare, thus being much more destructive and time-consuming
>than a reproduceable and frequent bug would be.
>
>If I understand correctly, E's execution model completely solves all three of
>these problems.

Well, not *completely*.  I try to always be careful to state the 
qualifications.  But I'll agree with "substantially" or "almost completely". 
(That's why I'll never be in marketing.) To whit:

* The qualifier on the first reason I actually had not yet stated:  E does 
allow certain external devices (expected to be prompt) to be called in a 
synchronous manner, such as reading from a (hopefully local) file, or 
"timer now()", which asks for the current time.  Such synchronously 
accessible external state may change by means other than the currently 
executing program.  While this may not actually be surprising in practice, 
it does violate my simple model of assumptions.

* We've been over the second qualifier, data-lock, whose accidental 
occurrence is astonishingly rare.

* On the third, E is not fully deterministic, and so is only replayable with 
some effort.  I like to say that E has "loggable nondeterminism" with a 
reasonable logging cost.  This enables deterministic replay.  Such logging 
and replay are not expected as of E 1.0.  In their absence, E's bugs are not 
technically reproducible, but tend to be so in practice.  More interestingly 
for your point, concurrency bugs in E programs (including data-lock) are no 
less reproducible than any other bug.


>So describing E as "deadlock free" may be describing only one of three valuable
>improvements for the working programmer.

Ok, so distribution requires concurrency and security.  On security, unless 
we screw up, we should be able to win hands down.  On concurrency, as you 
point out, we've got 3 killer advantages.  In addition, as of 0.8.10, once 
we have real pipelining (I know, I'm working on it), we should have a killer 
performance win for distribution per se, and one that continues to grow in 
direct proportion to Moore's law.

On persistence, I think we can position so it's not us vs Java 
serialization.  We'll probably be using Java's serialization to implement 
persistence anyway, as does Tyler's Acid and as does EJB.  (We currently 
expect to implement persistence on top of Acid, in which case we'd inherit 
this property anyway.)  Rather we should say that both distribution and 
persistence require serialization as a component, but Java's answer to 
*persistence* is EJB.  My sense is that EJB is so universally and strongly 
disliked that, to succeed at this positioning is to win the persistence battle.

In any case, all this just builds up our ammunition.  Each of us much chose 
our battles individually and well.  If ERights and/or Combex continues to 
focus on security as its main battle, I see no problem with that.


        Cheers,
        --MarkM