Processes and Communication (2)

[Gary D. Duzan]

=>>>    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.
=>
   I called it that because that is what it is called. RPC is a well
known Operating Systems concept, not a product, protocol, or
implementation.

=>>> An invoced method is called a 'thread'.
=>I think `invoked' should be righter.
=>
   Quite right. I was shooting for the root word of invocation and missed
slightly. Isn't English wonderful?

=>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.
=>
   Putting device access in special priveleged objects increases the
flexibility and aids the configuration of the system.

=>>>    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.
=>
   Where did I say that?

=>>>    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.

   The more functionality we move to objects, the more flexible the
system becomes. Actually, it is theoretically possible to have a
system with no kernel at all (given proper hardware protection
mechanisms.) In such a system, everything is just a piece of code.
That would be the ultimate in system flexibility. Of course, since
it is a terribly radical idea, a lot of people (including many on
this list :-) won't care for it. I can live with that. :-)

=>>> 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.

   What would you suggest adding that would preserve the basic notion
of objects interacting through calls to methods?

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