Processes and Communication (2)

[Gary D. Duzan]

   I don't think this went out properly the first time I posted it,
so here it is again. If you get it twice, I apologize.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




   This is an overview of my vision for processes and interprocess
communication in the MOOSE system. It is far from being a complete
specification, and I encourage discussion of the various features. I
have intentionally left out any implementation details or actual
example interface code so that we can decide on the abstract model
first and move on to the implementation once the model is ironed out.

   Entities in the MOOSE system are referred to as 'objects'. The
interface to an object is composed entirely of 'methods'. One object
communicates with another by 'invocing' a method on another object.
Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
An invoced method is called a 'thread'.

   Objects represent protected units of functionality in MOOSE. With
the exception of inheirited (non-virtual) base class code (libraries),
each object has a completely private, non-shared address space. The
kernel is reponsible for scheduling objects and providing resources as
needed. Each object has a specific protection level which determines
how the object's threads may directly modify the system hardware.

   An RPC call will contain information such as a remote object name,
the remote object's method name, permission information, and a set of
arguments to the method. The invocing thread is blocked, the message is
delivered to the destination object, the object executes the method
with the given arguments, and passes the return value (or error code)
in a message as a reply to the calling thread. Note that passing
pointers isn't useful, since objects have disjoint data spaces. There
are, however, techniques to improve performance when passing large data
items.

   The thread is the basic unit of execution within an object. A thread
can invoce a method of another object via an RPC. The calling thread is
blocked until the call is completed, but the other threads are allowed
to continue. The call is received by a thread in the target object that
waits for calls to that particular method. Threads can create other
threads to execute while others are blocked. This allows the object to
continue processing while waiting on the result, while maintaining
procedure call semantics.

   An object is created by an RPC call to an object with access to the
scheduler and resource allocator. An object with such access may also
destroy an object by descheduling it an deallocating its resources.
Each object will have an initial set of object names. This will
generally include the name of an object that holds the names of other
objects. Each object should include a method to determine the names of
its other methods.