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

[Gary D. Duzan]

In Message <2bf9bd0e.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>"> " is Dennis Marer
=>">> " is Gary D. Duzan
=>">>=>" is David Garfield
=>
=>>>    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.  
=>
   Well, if we use Ellie, we can always use future return objects. :-)

=>> 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.  
=>
   Sounds like we are going to do threads. Now the trick is to do
it portably and efficiently. We may also want to consider what sort
of protection among threads is required/possible.

=>>>    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?  
=>
   Very sparse address spaces and encryption can be used, as in the
Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
object numbers scattered around in it) may be sufficient for a local
system.

=>If IPC is not in the kernel, how do you communicate with the IPC?
=>
   Quite so. Unless the hardware has some IPC support, it has to
be in the kernel. The 386 seems to be one of the exceptions in that
the gates (if I remember correctly) can be used here. Other machines
aren't so fortunate. Regardless, it needs to be in the kernel API
whether it actually goes to the kernel or not.

=>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?  
=>
   Quite so. So are we going to implement StreetTalk for Moose too? :-)

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