Processes and Communication (2)

[Francois-Rene Rideau]

Here is my reply to our Time Lord:
>>    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'.
Why remote or whatever ? That's Microsoft-like name for things: they give
technical names to impress common users, and to show beginner programmers
that a technique much spoken about (because too longly and unjustly left
in the company's previous software) has (at last) been used.

>> An invoced method is called a 'thread'.
I think `invoked' should be righter.

>>    Objects represent protected units of functionality in MOOSE. With
>> the exception of inheirited (non-virtual) base class code (libraries),
(it's inherited)
>> each object has a completely private, non-shared address space. The
Hey ! You're interfering with implementation. From external view, the object
must cope with its methods. From high level, there are private members
(code or data), but even addressing space should be (IMHO) low-level enough
to be implementation dependant: we must also know that most processors
don't have the same protection scheme as the 386, when they have; so we
should rely on LLL interpreting and compiling to enforce non-interfering
between objects. That means LLL should be `high-level' enough to know
bounded arrays (not like C arrays).

>> 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.
To me, the Kernel should only connect objects to resources; the resource
managers provide what they have how they will. Object threads should NOT
modify the hardware anyhow; device drivers are there for that; object
threads should handle neither less nor more than their `local' own members.

>>    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.
 Again, identifying objects should be all to the impl'; IMHO, HLL provides
only `virtual' pointer types (among the which naming); but naming as only ID
for an object is too costly both in speed and memory, and doesn't prevent
more form bugs than any other pointing devices, it's only more directly
readable by humans (I'm FOR naming, but not as primary system pointing).
IDs should depend on implementation; for the 386 (only), I recommend a
a 32 or 64 bit word; it may be just an offset in some common segment (for
a 'we trust all assembly, what we do not trust is interpreted' system),
a 16 bit (Descriptor Table pointer/system index), and 16 bit segment pointer
(for a 'do what you want inside your object, but IOC is through the Kernel
only' system), or the same plus offset, or whatever.
 (by D.T. pointer, I mean first 4K in DT can be standard, while the remaining
is remapped in virtual memory)

>>    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 othere
>> threads to execute while others are blocked. This allows the object to
>> continue processing while waiting on the result, while maintaining
>> procedure call semantics.
 That's only allowing Kernel-managed sleeping for threads.

>>    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.
 Why so powerful objects ? An object may only destroy its own members; it
may of course willingly accept to destroy it on another ones' demand, but
that's another problem. Of course, the programmer may always be able to
ultimately call a persuasive enough object to obtain what he wishes.
>> 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.
That's my hierarchical dictionnaryy stuff: of course I agree; but again
naming shouldn't be the only pointing way.