Loose type checking in E

[Tyler Close]

At 11:02 AM 10/12/98 -0700, you wrote:
>Remember that the motivation for E was to create not merely concurrent
>systems but distributed systems. Distributed systems have a degree of
>inherent, uncontrollable asynchrony that means atomicity is achievable
>only at the most extreme cost in performance and complexity. So we
>gave that up as a losing cause. Giving it up, however, means that
>deadlock something is we can now live happily without.

For transactions between vats located on physically distant computers,
asynchronous communication has a pleasing symmetry with the reality of the
underlying hardware. I can see how one could design long-distance
transactions to take place in a single bulked-up send / receive pair.

My concern is that you may have stretched this paradigm beyond its natural
bounds. Asynchronous communication does not make sense for communication
between vats located on the same physical computer. This is bad since this
type of communication will be more prevalent.

>
>And don't discount just how difficult a problem creating deadlock free
>software is in a threaded environment.  Ancedotally, the majority of
>the really nasty debugging problems we had in developing EC Habitats
>-- in particular, in developing the underpinnings of what is now the E
>runtime library itself -- were deadlock problems in those few areas
>where we couldn't avoid threading. (We couldn't avoid threading when
>building on top of Java libraries for, e.g., I/O, that were
>blocking). One of our mantras became "Threads Are Evil".

This is like saying "Recursion is Evil" because some dopey C programmer
will try to break out of the recursion by doing a goto to some other line
in the program.

When doing multithreaded programming, you have to establish a certain code
of ethics that will not be broken. I agree that there are many unethical
programmers out there; however, I have found that it is possible to embed
this code of ethics within the way that the library is naturally used.

>
>Note that one of the problems with deadlock bugs is way you are
>vulnerable to them even (or especially) when they are in other
>people's software. For example, we had to concoct some truly horrific
>workarounds to deal with the fact that the Javasoft JVM garbage
>collector and storage allocator can deadlock against each other (!).

Yes, well, I think that the way that the Java software libraries have been
designed is tantamount to sabotage upon the entire software industry. I was
unaware of the possibility of deadlock between the garbage collector and
the storage allocator. This hurts.

>Creating reliable software is hard enough by itself.

It's pretty fun though isn't it?

ciao,
Tyler