IPC in MOOSE

[Francois-Rene Rideau]

>> Hi,
>> 
>> I've already started a private discussion with Gary about his IPC
>> ideas. In my opinion one should specify the design of IPC in a more
>> higher abstract level. Don't start discussions if it is efficiently 
>> programmable or whatsoever. It's specification time: Let's first define
>> what we want and then see how we can get it.
>> 
>> [...]
>> >    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'.
>>
>> I think, that's too deep. Let's simply say, that an object must be able
>> to invoke another object's method. (I don't like to mention how this should
>> be done, via RPC or not.)
ok for RPC being an excess; but the remaining seems good to me.

>> >    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.
the system should provide the resources; but the Kernel shall only establish
a link between asker and provider. As for protection level, why not accept
the you can use an object's methods iff you possess its ID ? It may be
clearer, more portable, easier to implement on a generic system, etc.

>> >    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, I suggest to implement a standard second way for errors and exceptions,
with an exception handler routine stack.

>> That's again too deep. Naming should be done by another object, eg. a 
>> NAME_SERVICE. This must exist, because objects must be able to publish 
>> themselves or their methods to the outer world. Thus, an object X which
>> want to be published invoke a methods of the NAME_SERVICE, which makes X
>> known within the NAME_SERVICE's scope:
>> 
>> +---+              +--------------+
>> | X |---publish--->| NAME_SERVICE |
>> +---+              +--------------+
>> 
>> If an object Y wants to use X it first must determine X's location. Therefore
>> it asks its NAME_SERVICE, which returns X location:
>> 
>> +---+                           +--------------+
>> |   |---ask for X's location--->|              |
>> | Y |                           | NAME_SERVICE |
>> |   |<---return X's location----|              |
>> +---+                           +--------------+
>> 
>> Now Y can simply invoke a method from X:
>> 
>> +---+             +---+
>> | Y |---invoke--->| X |
>> +---+             +---+
>> 
>> With this design it is possible only to contact published objects. More: You
>> have to contact the right NAME_SERVICE to get a desired object's location. 
>> Think of several applications (which are O B J E C T S), which all have their 
>> own NAME_SERVICE available. Several objects with the same name may coexist
>> even with different functionality but the application's local NAME_SERVICE
>> secures, that the application is only able to invoke methods of well known
>> objects. 
>> 
>> Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
>> create hierachical or other name scopes. If an object's location cannot be
>> resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
>> is automatically invoked.
>> 
>> What I currently left out is, how an object received knowledge of "its"
>> NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
>> of the desired object.) If you want, I can try to present you a design
>> idea.
again, I do agree with Peter's remark, but else support Gary's views (perhaps
are we going to agree upon that 'dictionnary' stuff as I call it - call it as
you may).

>> >    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.
>> 
>> That's again too deep for the first ROI specification.
Well Gary's just anticipating on implementation.

>> >    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. 
>> 
>> Hmm, what does object creation have to do with ROI? (BTW: In my opinion
>> an application which cannot receive access to an object, simply create an
>> instance of a new one. Then the object can make itself available via the 
>> application's NAME_SERVICE or a predefined one. Of course the application
>> object already know the object's location and can invoke methods immediately.)
>> 
>> > Each object should include a method to determine the names of
>> > its other methods.
>> 
>> NO! Publish all methods which should be accessable by other objects to the
>> NAME_SERVICE! Seperate the services (provided by objects) and it's management
>> (provided by NAME_SERVICEs). Without such separation each time you include
>> a new service you must also change the determination method. Don't mix up
>> services and their availability.
Uh, well, both ! It may be useful to ask the method's name directly to the
object without having to look through the whole table (but both methods are
equivalent; you can build the name list from the objects with a method list
method; or you can build a method list method from a name list; so to me,
that's up to implementation)

>> Cheers,
>> 
>> Peter 
>>