Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!purdue!gatech!udel!rminnich
From: rminnich@udel.EDU (Ron Minnich)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPC (1): Ports & Messages
Keywords: InterProgram Communication, tools
Message-ID: <1467@louie.udel.EDU>
Date: 10 Mar 88 02:57:20 GMT
References: <7409@agate.BERKELEY.EDU> <1401@louie.udel.EDU> <7543@agate.BERKELEY.EDU> <44811@sun.uucp>
Reply-To: rminnich@udel.EDU (Ron Minnich)
Organization: University of Delaware
Lines: 17

In article <44811@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>Have you considered using a new mechanisim that uses a buffer pool that
>your task doesn't "own". It works like this, you call "OpenIPCPort()"
>and the library does, and  allocates a unique port for you. Then you
>Put messages on it like a PIPE: by writing them in a block. The
> (and more good stuff )
   This is pretty much what i was after with a PORTPIPE: device. 
Also tasks could indicate that they are willing to give up 
ownership of the port in which case the other task would get it 
for a while, and, ..., no data need be copied. In other words
PORTPIPE: could run in a 'data copy mode' or, for processes that 
were willing to be nice and wanted to buy the performance, they
could operate in a 'quid pro quo' mode (much as messages do now)
where you give up ownership of the shared resource and gain performance
thereby.
-- 
ron (rminnich@udel.edu)