ORG, IPC, pem 05/17/93 [djg22] [dpm11] [djg23]

[David Garfield]

"> " is Dennis Marer
">> " is Gary D. Duzan
">>=>" is David Garfield (me)

>>=>Well, the big problem with providing only synchronous IPC is that you
>>=>CANNOT make asynchronous I/O out of it without having a second thread.
>>=>The standard way in Unix to do I/O reading from two different sources
>>=>is to make one process reading each source.  Unix now has a kludge
>>=>called select() that allows a program to identify the descriptors with
>>=>available I/O, but this relies on the system and process being able to
>>=>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
>>=>queues a number of asynchronous I/O calls on each channel, and
>>=>processes the data after it is transferred to your processes own space
>>=>and you are notified.  I feel this is a much more satisfactory
>>=>solution.
>>=>
>>    Well, presumably you would want to different things with data
>> from different sources, so threads would make sense, and if they
>> are lightweight enough, performance should be ok. I think the main
>> argument is that object-invocation is basically synchronous, so an
>> object-oriented operating system should be synchronous.

"basically synchronous", but only when you do simple stuff.  More 
complicated stuff requires more advanced techniques.  

> I also think threads make sense.  As far as being lightweight, this too is
> achievable.  Memory consumption (from a programmers perspective) is close
> to nothing per thread, and task switching time could also be reduced by
> having a more lightweight switch to go between threads in a process.

Agreed.  These threads need only grab a copy of the loaded image's 
process space, add a stack, copy parameters, and run.  

>>=>The obvious way to avoid this is to not make the parameter be the
>>=>object ID.  If Unix had used their equivalent, you would pass inode
>>=>numbers to read() and write() calls.  The obvious solution is exactly
>>=>the same that Unix used, you open() the Object and get a process-
>>=>specific identifier.  There is then no possibility of forging
>>=>anything, and the authorizations are all checked only once.
>>=>
>>    This is certainly one way of doing it, but it adds a lot of
>> state and complexity to the kernel, which is exactly where not
>> to put complexity in a microkernel-based system.

Protection is REQUIRED in an operating system.  If we don't have it, 
we get a system known as DOS.  Protection includes a necessity for the 
OS to protect objects from unauthorized processes.  Any other 
suggestions on this that are proof against forgery?  

> Ah, I still don't believe in the kernel is where IPC should go - support for
> IPC, yes (shared memory, etc) but not the IPC itself.  Maybe.  I dunno.

If IPC is not in the kernel, how do you communicate with the IPC?

>>=>On the subject of objects on remote machines, I believe that the
>>=>correct way to do this is to access an object of a "remote access
>>=>class", and tell it a remote machine and object identification to
>>=>connect to.  Once it is connected, all method calls get passed to the
>>=>remote machine.  [This might be a seperate meta-class, just so we can
>>=>grab all method calls at one point, while not increasing the overhead
>>=>for normal objects.]  Once you terminate access to the local object,
>>=>the network connection is dropped, and the remote machines object is
>>=>no longer used.
>>=>
>>    A remote access object is a good idea, but we shouldn't use a
>> connection-oriented protocol to do the job of an RPC. We can also
>> implement TCP/IP, SNA, and Vines objects if we want.
>
> In OOP terms, creating an instance of a "remote access class" establishes
> the connection (by calling its constructor); when it is destroyed, it calls
> its destructor to terminate the connection.
>
> I use the term "connection" loosely - I don't mean to imply any protocol here.
> Ideally, network connections should be possible independent of the protocol.
> That's ideally...

Well, connection may be used loosely here, but in some ways, a 
connection-oriented protocol (like TCP) is a GOOD thing.  There are 
things that will work out much easier if it is not necessary to 
establish one or more objects, connect them appropriately, use them, 
and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
sense for something as simple as a disk access (NFS), but not for 
everything.  Can you imagine trying to access a remote Vines 
connection-oriented connection over anything other than a connection-
oriented protocol?  

-- David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com