Summary: E / Erlang integration

[Michael FIG]

Thank you for this excellent post.  I greatly value being able to learn from people who have experience with the hard problems.

Now that I've actually been working on a prototype implementation, I'm getting closer to something that is close enough to E's structure hopefully to spur future discussion.  I'm still heading towards a "capabilities on Erlang" library, with a model for execution of untrusted code, but I'm curious if the end result will be useful to others.

It's been a fun exercise for me, at the very least.

-- 
Michael FIG <fig@REDACTED>

----- Original Message -----
From: Ulf Wiger (AL/EAB) <ulf.wiger@REDACTED>
To: Michael FIG <fig@REDACTED>
Cc: erlang-questions@REDACTED, Discussion of E and other capability languages <e-lang@REDACTED>
Sent: Tuesday, June 20, 2006 2:52:29 AM GMT-0200
Subject: RE: Summary: E / Erlang integration

 
> From: Michael FIG wrote:
> With both of these functions non-blocking, there is a 
> guarantee that deadlock is impossible.  That's the main 
> property of E programs that I'd like to achieve in
> this library.


The Erlang philosophy is to provide for synchronous wrappers around
asynchronous message passing. Waiting for a response can (and often is)
blocking. To reduce the "problem" of blocking, processes are made
lightweight enought that it should be feasible to create one concurrent
process for each naturally concurrent activity. Thus, the natural thing
to do when one needs a response from another process would be to stop
and wait for it.

My opinion is that it is dangerous to advocate completely non-blocking
semantics in complex programs, unless one makes abundantly clear what
problems can come of it. I think one of the biggest problems today in
the design of complex control logic is the inability to avoid complexity
explosion in the state-event matrix. It was suggested that E is able to
avoid this, and from a cursory glance at the code in this thread and at
erights.org, it seems plausible. I'm not convinced yet that it will be
intuitive enough, but maybe...

What I do know is that careless use of non-blocking programming in
complex control scenarios can very easily blow up in your face, leaving
you with an unintelligible and unmanageable mess. What's worse - very
few programmers involved in this type of programming are actually aware
of what causes these problems.

Even in Erlang, many programmers prefer 'cast' to 'call' for performance
reasons and/or fear of deadlock, but cast and call are semantically
different! If one needs a reply from the other process, a call is
natural. Deadlock can occur if two processes try to call each other at
the same time (this is the simplest form of deadlock), but changing call
to cast doesn't change this - deadlock can still occur, but it will be
immensely more difficult to detect.

There is a wealth of documentation on deadlock avoidance in the database
community. There are also good algorithms, such as the 'banker's
algorithm' to ensure freedom of deadlock. The reason why no DBMSs use
the algorithm is that it requires all resource dependencies to be known
up-front. Deadlock detection is relatively easy to implement, unless the
system is distributed. Deadlock prevention works in a distributed
setting, but may cause 'phantom deadlocks'. One has to pick the right
poison.

Erlang doesn't solve the problem of deadlock, just as it doesn't solve
the problem of complexity explosion. It has a programming model that
seems pretty intuitive and, if followed, tends to reduce (perhaps
eliminate) some of the very hairiest problems. You'll be left with some
smaller problems (unnecessary serialization, forgotten messages in
message queues, etc.) but these are relatively easy to detect and solve.

Regards,
Ulf W

-- 
MarkeTel Systems has made every effort to ensure this message is
virus-free.  Our mail server uses multiple virus scanners to
provide maximum protection.