The EROS Constructor

[Guy Bormann]

On Wed, 2005-10-12 at 05:03 +0200, address@hidden wrote:
> Message: 2
> Date: Tue, 11 Oct 2005 16:24:11 -0400
> From: "Jonathan S. Shapiro" <address@hidden>
> Subject: The EROS Constructor
> To: Hurd-L4 Discussions <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain
> 
> My XMMS example will need to wait for tonight, because I need to go meet
> my wife, but I think I can finish the constructor explanation without
> getting divorced.
:o)

> In EROS, the basic mechanism for process construction is called a
> "constructor". I think that if I explain how the mechanism works and the
> relationships that it enforces, some of the other things I have said
> will become easier to understand. At the very least, I will be able to
> walk people through how these apparently strange relationships are
> achieved.
So, actually, you have a flat process relationship, as if you could request
the UNIX init process to create any process, not just the minimal boot set?
That leaves open the possibility that any process can play the init process.

> Next, it goes to the "metaconstructor" (this used to be called the
> "constructor constructor", for reasons that will shortly become clear,
> but that is just impossible to say out loud). The metaconstructor is a
> server that is part of the system TCB. It is available to everyone.
So, any process *can* play the init process? Because child processes can
reject their parents, does this lead to equivalence classes of process
trees which share or are traceable to a common "official" space bank?
(I don't really have a point here, I just want to understand the
structure.)
  BTW, in GoF design pattern speak, could we call the metaconstructor a
constructor factory? And the constructor is actually a "foo program"
Factory, no? (This would "unconfuse" it with the notion of constructor
in OOD/P because in that context a constructor is responsible of
(apparent) self-assembly, which seems not to be the case for process
constructors in EROS.) (This is not inspired by the classloading
mechanism of Java applets(!not applications) into a JVM, is it?)

Sorry, this is mere word play but I don't like semantic overloading,
except in class implementation :-)

Guy

PS : Go for the cartoonist. You might be able to support another RA
from the royalties :-)