Xref: utzoo comp.sys.amiga:16443 comp.sys.amiga.tech:85 Path: utzoo!mnetor!uunet!husc6!ncar!ames!sunybcs!ugmiker From: ugmiker@sunybcs (Michael Reilly) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Some "general" IPC questions..... I think... Message-ID: <9490@sunybcs.UUCP> Date: 22 Mar 88 02:53:28 GMT Sender: nobody@sunybcs.UUCP Reply-To: ugmiker@sunybcs.UUCP (Michael Reilly) Organization: SUNY/Buffalo Computer Science Lines: 70 Keywords: Actual message passing "system".. overhead.... I have a couple of questions about the ipc ideas floating around so far, they mostly have to do with overhead of a few of the proposals talked about to date. These questions might be slightly redundant, or taken for granted on the net so far, but I am just wondering what memory, or cpu, hogging we are willing to give to this ipc library, or broker...??? 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? 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 phone line, it would (i guess) be implemented as a pipe/port that would be used to read and write messages from and to the two process, much like unix IPC. Problems: how do these two processes get together, is there some central "message broker" or operator that would connect a process that "wants something done" to a process that "can 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. 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. 3) a reserved spot, or mailbox method, where each process knows where to check if it is wanted to do something, so it would not have to read the whole blackboard, and also knows where to send to when it's requests for help on certain projects. Problems:This again means any process that needs something has to know where to find the help it needs, or where to look to find the help it needs. Or each process has to send a copy of the help it needs to every process with a mailbox, to see if any of them can help. 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... 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?? just wondering.... mike Mike Reilly President of UGCSA University of Buffalo Computer Science csnet: ugmiker@buffalo.CSNET uucp: ..!{nike|watmath,alegra,decvax}!sunybcs!ugmiker BITNET: ugmiker@sunybcs.BITNET <-OR-> ACSCMPR@ubvmsc.BITNET