[E-Lang] Re: Why Not Coroutines? (was: Deadlock-free [was
what is good about E?])
Mark S. Miller
Wed, 18 Jul 2001 21:02:23 -0700
At 08:10 PM Wednesday 7/18/01, firstname.lastname@example.org 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
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.