It's Time to Abandon Insecure Languages

[Mark S. Miller]

At 01:59 PM 7/20/2002 Saturday, jamesd at echeque.com wrote:
>    --
>On 20 Jul 2002 at 13:41, Ben Laurie wrote:
>> E is interesting for far more reasons that just buffer overflows 
>> - in particular, it is capabilities from the ground up. Not to 
>> mention highly cool for distributed applications.
>
>It seems like a really brilliant concept if it works, a solution 
>to the presently unsolved problem of distributed computing.

Thank you.  It's been working well for us.  Most of the brilliant concepts 
in E aren't ours, but are thirty years or so old.  In particular, Hewitt's 
Actors had both distributed lambda-based capability security and 
deadlock-free event-loop concurrency.  See 
http://www.erights.org/history/overview.html for more on the history of 
influences on E.


>However I have a suspicion that instead of the presently 
>intolerable problem of bugs resulting in rare, non deterministic 
>deadlocks, we will get the problem of bugs resulting in rare, non 
>deterministic catch probs.

"catch probs"?


>With E, as with C, we get multithreaded code executed in non 
>deterministic order.  It appears to me that it still happen that a 
>certain rare and unusual execution order can reveal a bug, the bug 
>being of the form that if G is executed before Y is executed,
>which normally never happens, then the "when" clause for X can
>never be executed until the "when" clause for Y is executed, but
>the "when" clause for Y can never be executed until the "when"
>clause for X is executed -- the old familiar multithreading
>problem that has destroyed so many projects and careers. in a new
>and slightly different guise.

Correct, and very perceptive.  We refer to this as Data Lock.  However, the 
different guise causes an importantly different effect.


>Is there some feature of the syntax or error handling of E that 
>prevents one writing such code, 


E does not enable one to fully avoid making Data Lock bugs, but does make
such bugs amazingly rare, as explained at 
http://www.eros-os.org/pipermail/e-lang/2001-May/005287.html .  See also 
http://www.erights.org/elib/concurrency/event-loop.html .  During the six 
years of use of E and its ancestor Original-E (which used the same 
paradigms), I can only recall one occurrence of an accidental Data Lock bug. 
Although the explanations at those URLs helps explain why, I remain 
mystified why there were so *many* fewer Data Locks than there would have 
been DeadLocks.


>or reliably detects the error if one does write it? 

Reliably?  No.  More reliably?  Yes.

Since we've only had one genuine occurrence of a Data Lock, we have no 
meaningful statistics.  You are also correct that Data Locks can be 
non-deterministic and so throw you into non-reproducible debugging hell.  
However, in a non-deterministic system, all bugs may be non-reproducible, 
because the computation can diverge before that point in the computation is 
reached.  Classic Deadlock bugs are more non-reproducible than that, because 
they are inherently provoked by a race condition.  In E, Data Locks are no 
more non-reproducible than any other kind of bug in a non-deterministic 
system.  Further, E's non-determinism is very constrained (what we call 
"loggable non-determinism"), leading to less non-reproducibility in general.



----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com