Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!mcnc!ece-csc!ncrcae!ncr-sd!crash!pnet01!haitex
From: haitex@pnet01.cts.com (Wade Bickel)
Newsgroups: comp.sys.amiga
Subject: An alternative IPC system
Message-ID: <2783@crash.cts.com>
Date: 7 Apr 88 12:36:59 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 48



     The IPC (Inter-Process-Communications) Discussion still rambles forth
   without focus...

                    ... so I guess I'll add my two bits :^).


	I suggest that IPC consist of a mechanism for registering and
   lauching tasks, and manageing shared memory and code.  Leave the details
   beyond this to the programmers who need the facility.  Standards for
   things such as file transfer formats can be hashed out later by those
   who have need for them.

        Basically, I envision the mechanism as one which handles the
   following:

		1)  Registration of New IPC recognized tasks. On startup
                      a user program needs to go through a registration
		      process to establish communications with IPC.

		2)  Allocation/Deallocation of Memory in response to 
		      registered client programs.  This space would be
		      available for any use, but the facillity is 
		      needed for shared memory handling.

		3)  Handling of a shared code facility.

		4)  creation of connected message ports for client tasks.

	        5)  It might be desireable to have process which spawn
                      sub-tasks to be able to do so as a request to
		      IPC.

	In this way the coding of the IPC mechanism can be kept to a
   reasonable level and no limitations will be imposed.  The biggest
   hurdle would creating an expanded message port handler to allow
   larger numbers of message ports.


						     Thanks,


							     Wade.


UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM