Xref: utzoo comp.sys.amiga:16935 comp.sys.amiga.tech:136
Path: utzoo!yunexus!unicus!craig
From: craig@unicus.UUCP (Craig D. Hubley)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Some "general" IPC questions..... I think...
Message-ID: <2456@unicus.UUCP>
Date: 30 Mar 88 04:10:55 GMT
Article-I.D.: unicus.2456
Posted: Tue Mar 29 23:10:55 1988
References: <9490@sunybcs.UUCP>
Reply-To: craig@Unicus.COM (Craig D. Hubley)
Organization: Unicus Software Inc., Toronto, Ont.
Lines: 105

In article <9490@sunybcs.UUCP> ugmiker@sunybcs.UUCP (Michael Reilly) writes:
>	How much memory would our ipc.library take up, would it be a large
>enough amount of space to make us think about a different type of system? 

Well, if that were the case, it wouldn't be much use.  The major space-eater
would be (as always) the nice interface so that programmers wouldn't have
to look for umpteen kinds of standard messages.  Those that had big 
objections to the space used could always look for the messages on the port
themselves, but with the caveat that future versions of the protocol might
not be compatible.  For commercial programs, large anyway, the friendly
and safe approach would be preferred.

>	With the object oriented approach (which I like) how will each 
>process talk to  the other processes? There are a few different ways we
>could implement this, each with thier own drawbacks...
>
>	1) The old process to processs line, much like a person to person 
>
>		do that something".  But then there is also the overhead of 
>		the operator, and the problem of each new process coming in,
>		"logging" in with the operator.  Also where is the operator
>		going to keep the lists of who does what, and who wants what,
>		and where to find each program, if it does not exist in the 
>		system at the time.

The `operator', which is a good name by the way, would have to keep the lists
of services offered and requested and in use, and would have to run at the 
same time, as a high-priority process.  You might also want to have 
the option of swapping it out, with all of that information saved to a file,
and restoring it when the emergency has passed.  But under normal circumstances,
it should exist in the system at the same time.

The process-to-process line is useful for two programs that must send large
amounts of data back and/or forth in small chunks, like a pipe.  However,
it costs almost nothing to have a broker/waysandmeans/operator perform a
`marriage' first, and keep track of their connection until it is broken,
and thereby be able to hold off other requests until the service becomes
available again.

>	2) A blackboard, or party line communication method, where each process
>	   reads and writes to one piece of "shared" memory.  The processes 
>	   "write" on the blackboard, and tell all the other processes what it
>	   can do, and reads what all of the other processes need done.
>		Problems:how big is this "shared" memory, of course it should
>		be dynamically sized, but how large would we want it to get, and
>		how long should a message stay on the blackboard before getting
>		"erased", if a messge doesn't get replied to, but we know we 
>		want every message replied to.

This model exists also, but the *processes* do not write and check on the
blackboard, as this would require them to know much about the system and
there would still have to be a `blackboard manager'.  Rather, the broker
maintains the blackboard and answers questions about it.  Messages that
are looking for something unavailable will be held until the broker is sure
that nothing can be made available for it in time (as defined in the call).
This is a matter of seeing if the service required is loaded, seeing if it
is in use, and attempting to load it or wait for it to be freed.  Some form
of pre-emption could be defined, but that would be tricky.  The broker itself
would have to respond to the message, with a failure.

>	3) a reserved spot, or mailbox method, where each process knows where to

Having a broker with a well-organized blackboard and its own search methods
is nearly as efficient as a well-written `go right to the memory location
and see if that bit is a 1' approach, considering that calls would not be 
made in tight loops. :-)  Having processes be as stupid as possible is very
desirable.   This intelligence belongs on the service level, which is 
abstracted one level from the process level.  I want *all* ANIM viewers to
know about my animation, not just JoeAnimator.  A mailbox for each type of
service is essentially what the broker would implement, at least for messages
that were willing to wait around to be answered.

>	4) a combination of 2 and 3, a reserved blackboard method, with a 
>	   special areas of the blackboard reserved for special types of 
>	   functions, or special "groups" of "objects" in our object oriented 
>	   method.   
>		problems: problems for this would be a restricted (hopefully)
>		union of the problems of 2 and 3...

I hope the problems would be restricted, too, since that's what I'm thinking of.

>With the "ways and means" method, how large would this "ways and means" 
>program be??? it seems like it has alot of jobs, would it be excessively large??

Yes, it has a lot of jobs, but most of these jobs are a screenful of C, at
most.  For instance, checking to see whether a service is available at the
present time would just be a matter of finding a name in a name table.
The port address for that service is just another field in that table.
Flagging it as `in use' after sending its address off to another process
is just flipping a flag.  Loading it if it's not available is looking
up a filename, plus the load operation (if this is desired).  None of these
things is more than a tiny chunk of code, once the data structure of 
service names, ports that offer them, and programs that fire them up
is in place.  You might have some lags as you start up, but that's the
most time-intensive thing about using an 8 meg machine without virtual
memory anyway.

>				just wondering....
>					mike
Good questions.  I'm going to go away and think about them some more.

	Craig Hubley, Unicus Corporation, Toronto, Ont.
	craig@Unicus.COM				(Internet)
	{uunet!mnetor, utzoo!utcsri}!unicus!craig	(dumb uucp)
	mnetor!unicus!craig@uunet.uu.net		(dumb arpa)