Where IS everybody

[Gary D. Duzan]

In Message <9305161248.AA05839@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>Maybe there's a possibility to get things started. Mmh, I think we all do agr
ee,
=>that the basic mechanism which must be provided by the kernel (Moose) must
=>be interprocess communication. (Or: message passing).
=>
   Absolutely.

=>Therefore we have to create a module, which provides an interface with three
=>primitives, namely:
=>
=>	send(destination, message)
=>	receive(from, message)
=>	reply(to)
=>
=>I suggest synchronous ipc, because it seems to me to be the basis of
=>any other ipc types.
=>
   I used to be of this opinion, but I've changed my mind somewhat. I
still think that the basic *user* level IPC mechanism should be based
on blocking RPC, as you have described. However, there are some
advantages to building synchonous calls out of asynchronous calls.
(i.e. asynch_send(dest, msg) -> reply_id; block(reply_id)) For example,
a user-level thread package would be much easier to implement in this
scenario. On the other hand, advances in technology may allow us
eventually to use normal function calls to implement IPC, which is
basically blocking the caller untill the function returns, so we should
make it possible to use such a technology as it becomes available.
   So I would advise making IPC asynchronous at the system level and
providing standard library (or langauge-imbedded) functions for
synchrounous IPC. When the secure function call technology appears, we
can simply change the library function (compiler) to use the new call.

=>Where we still have to get to an agreement is:
=>
=>o How looks a destination address? 
=>  Should it look like this: (machine address, object id, method id)
=>  or only like this: (object id, method id)
=>  or like this: (machine address, process id)
=>  or: ???
=>
   I don't think including the machine address is necessary, and not
particularly desirable as part of a system that may very well be
stand-alone. Therefore, (object id, method id [, authorization])
would seem to be the logical answer. To support object server
objects, I would suggest a two-level object id (external and
internal), or possibly object id classes (analogous to Internet
network classes and subnets.) This would allow for addressing either
entire system objects or smaller objects managed by the larger system
object with no change in call syntax. Objects on remote machines
could be accessed via a network object server object that does
translation and forwards calls to a network object server object on
the destination machine, which does the actual call.

=>Let me know what you think. If you want, I can try to write a draft about
=>the IPC interface. I will wait for Dennis' next spec's because it will
=>give a us a basis. Ok?
=>
   Sounds good to me.

=>Next: Forgive my english, I've had a long long night yesterday and it seems
=>that I'm standing 1 m besides myself ...
=>
   Your English looks ok to me. Get some rest; I'm sure you've earned
it.

=>Bye,
=>
=>Peter
=>
=>P.S: One for the compiler designer. I don't think, that the missing of a
=>compiler is a thing which disables us to start writing. If you provide the
=>possibility to use interfaces to other languages (preferably some which are
=>in common use, like C++), it's possible to start writing. (BTW: As some code
=>of the kernel must be done in Assembler, there must be at last an interface
=>to that sort of language ...)

   Indeed. I'd rather use something better now, but if it isn't
available, we can't exactly use it now, can we?

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