Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!pyramid!prls!philabs!sbcs!root
From: root@sbcs.sunysb.edu (SBCS Systems Staff)
Newsgroups: comp.sys.amiga.tech
Subject: Re: An alternative IPC system
Message-ID: <1202@sbcs.sunysb.edu>
Date: 23 Apr 88 18:55:05 GMT
References: <2783@crash.cts.com> <12379@orchid.waterloo.edu> <1833@sugar.UUCP> <9132@agate.BERKELEY.EDU>
Organization: State University of New York at Stony Brook
Lines: 92

In article <9132@agate.BERKELEY.EDU>, pete@violet.berkeley.edu (Pete Goodeve) writes:
> 
> memory box we have in front of us now.  I'm NOT saying we shouldn't look
> forward to multiprocessor (like Transputer?!) distributed systems, but we
> mustn't hamstring local processes by insisting that they obey all the
> restrictions of that environment.

	Actually Peter, given the MMU's that will be present in future designs
	copying is not much of an evil at all (MACH).  I would guess that
	since messages tend to be small (eg mouse movements generate a lot
	of small messages), copying is not much overhead even on a non
	MMU system.
	
	Side comment: if we're thinking speed, then the noun "Transputer"
	doesn't belong in this article.  The T414/T800 have to be one of the
	slowest, most expensive CPU families I've used.

> In fact the Port/Message environment built into the Exec is already far
> more suitable. We can address messages to ports rather than to processes
> (as V does) and we can use meaningful strings, rather than 32-bit IDs, to

	I didn't propose that we limit ourselves *just* to the IPC
	semantics presented by V.  I had suggested that V be
	studied as a successful attempt at constructing a message based
	system.  Agreed that we would want to drop the process -> process,
	synchronous semantics of V.

	The issue of how naming is handled at the lowest levels is just a 
	matter of taste.  Sure with proper alignment you probably can derive 
	almost the same performance using short strings or 32 bit ID's.  I 
	would prefer the 32 bit ID's, as once the protocols are up and 
	running I don't want to spend packet space on names (plus we would
	not violate the VMTP standard for non existent or trivial gains).  
	It makes far more sense to specify a nameserver to go ASCII -> ID 
	once than have to pay on a per packet basis.

> Where we really part company with V, though, is in our approach to
> accessing data.  In a distributed system, you usually don't have direct
> access to a block of data at a remote site, so V's message protocol is
> based on COPYING.  Further, copying can only happen during "rendezvous" (to
> borrow a term from a DoDdery language) -- i.e. while the sender is
> SUSPENDED.  If you've been following the discussion on the net, though,

	Deviate from the suspended semantics.  No problem.  

> you'll realize that one of our main concerns has been speed: it is much
> better to pass the receiver process a pointer to the data (and permission
> to play with it) than to copy large blocks; saves memory too -- especially
> when you're passing bit maps around.

	Yes speed is a concern.  I would hope that the FOCUS of the
	design is on extensibility.  With 680[23]0's soon, home RISC on
	the horizon, the only way you'll avoid speed is by coding the thing
	in Prolog :-). 

> Past articles in this discussion have dealt at fair length with the
> different constraints on local and network message passing.  There are lots
> of things that are reasonable to pass to a local process, but that make no
> sense over a network -- things like port addresses, file locks, and file
> handles.  And think of a linked list:  locally, all you have to do is pass
> a pointer to the head, but for shipping out on a net you have to
> disassemble it, send it item by item, and reassemble it (with local
> pointers) at the other end.

	Yes, but the point is that if we get people used to a non local
	model of communication, we still get to play local optimizations
	in a transparent way, and at the same time get something that may
	be used in a networked environment.

> > We shouldn't reinvent the wheel if we don't have to. [.....]
>  Yes, but you don't want to put a tractor wheel on a bike...

	And of course we should be able to find out that tractor wheels
	on bicycles are a Bad Thing by reading, not by implementing :-).
	Evaluating various design decisions is hardly ever as obvious
	as the example you've suggested.

> >     our primitives).  This method must allow for client and server to be on
> >     different machines.
> See the discussion above.  I suspect a "distributed IPC kernel" on the
> Amiga will take the form of a local server that knows how to make messages
> suitable for net transmission, and complains if it can't.  Our IPCMessage
> format is designed to make this possible even though the server doesn't
> know the nature of the message data.

	I doubt you can do this transparently.  Example:  process A sends
	a handle to local screen memory to process B.  What to I do if
	the size of screen memory passed is implicitly assumed by prior
	agreement of A&B and is not sent as part of the message?  

> BTW -- Can we now move this discussion over to comp.sys.amiga.tech, please?
> ...At least when we start any new threads.

	Done.

						Rick Spanbauer
						SUNY/Stony Brook