a few thoughts

[Kragen Sitaker]

Simple directories don't need processes to hold them.  They can be
implemented as nodes holding a key to a node containing keys and a key
to a page containing their names and traversed by library routines.  As
long as you can do anything with a start key you can do with a page or
node key, the library can be fairly oblivious to directories
implemented in other ways.

This is probably a bad idea for extensibility.


Rob is, of course, correct about thinnings: while you only inherit a
method from one superclass (or super-interface), you may have several
thinnings that allow it.


I'm not sure that downcasting in Java is a design flaw; in particular,
it makes possible the implementation of generic and heterogeneous
container classes, such as the directories being discussed.  If you
have two chunks of code exchanging Walnuts through a Vector, they
should be allowed to get the Walnuts as Walnuts, rather than having to
treat them as Objects and invoke polymorphic Object methods overridden
by Walnuts in order to get Walnut behavior out of them.

(Of course, if the Vector can just remember that they are Walnuts, you
have solved the problem.  You can do this in Haskell, at least for
built-in containers, and you can do it in C++ with templates, but not
in Java.)

Likewise, I might like to have some set of EROS programs that expect
that the ".." entry of a Dionysix directory process is a Dionysix
directory.


The L4 HotOS 97 paper "Achieved IPC Performance" claims <1uS IPCs on
Pentium-166s.  Is this bogus? If not, why is EROS fast-path IPC pipe
latency an order of magnitude slower at 18uS?  (I know it involves
several IPCs, but ten?)

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves        
possess.                                                                        
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]