Nested Processes

With few notable exceptions (GrassHopper) most systems have simple tables of processes managed by a dedicated component. This scheme is ugly, inflexible, not ExoKernel, and works only in a very narrow and limited sense.

The solution is obviously to generalize the data structure involved. Instead of a set or ordered collection, use a tree. Instead of a set of independent processes in a single predefined location, have an extensible set of nested processes defining their own locations.

What that means precisely is that within TheObjectGraph which any process exports, one can find the building blocks (code, data, et cetera) for an executable process which the nesting process can call upon at will.

There are at least three ways of implementing nested processes.

First is the way grasshopper did it.

Second involves a simple yet high-level model of execution. Processes exist within other processes, but they are made live by the scheduler which loads them into memory, executes them, then stores them back wherever they belong. Sending a message into a process requires the component to send a message outside of itself to the scheduler. Sending a message outside of a process (to the component that contains it) requires defining a primitive intercomponent send operation that sends the requested message to a process-specific edge in the scheduler. This scheme has the disadvantages of being inelegant, non-local, centralized, not exokernel, and causing infinite regress.

Why is it I keep hearing 'not exokernel' as though it is, somehow, a mark of doom? ExoKernel has yet to truly prove itself. Further, the third method (below) simply forces processes into the role of secure-mux layers for their child processes.The ExoKernel concept does not require that all child processes suckle from the parent.

Third involves a subtle but low-level model of execution. The scheduler is no longer responsible for processes at all. Nor is there any component in the system responsible for processes, managing the address space, RAM, the CPU or anything else of that nature. Rather than having a dedicated component for any of these things, each and every process inherits these resources from its parent process, manages them for itself by itself, only to finally turn around and hand them out to its child processes (which it manages also). This scheme is elegant, flexible, powerful and exokernel.

MacOs prior to MacOsX made processes responsible for their own scheduling. It was a disaster, and avoiding this was one of the main reasons for the shift of MacOs to Unix. -- JasonGrossman

BlueAbyss calls for processes nested within each other in accordance with the third scheme.