Xref: utzoo comp.sys.amiga.tech:11 comp.sys.amiga:15711
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!udel!rminnich
From: rminnich@udel.EDU (Ron Minnich)
Newsgroups: comp.sys.amiga.tech,comp.sys.amiga
Subject: Re: IPC (1): Ports & Messages
Message-ID: <1437@louie.udel.EDU>
Date: 9 Mar 88 15:02:48 GMT
References: <7409@agate.BERKELEY.EDU> <1401@louie.udel.EDU> <7543@agate.BERKELEY.EDU>
Reply-To: rminnich@udel.EDU (Ron Minnich)
Organization: University of Delaware
Lines: 19
Keywords: InterProgram Communication, tools

In article <7543@agate.BERKELEY.EDU> pete@violet.berkeley.edu.UUCP ( Pete Goodeve ) writes:
>I'm not sure I follow your line of reasoning there, but there are some
>fundamental problems I see in basing everything on pipes: they're basically
>byte serial, which is very inconvenient for structured data, and even more
>important they involve buffering and therefore COPYING of data -- a lot of
>overhead.  Messages on the other hand don't move -- they're just inserted
>in a list, so making a lot of data available to another task can be very
>fast.  For a general IPC scheme, I think we have to be concerned with
>speed.
   Good point. What i am after is a PORTPIPE: i  guess- a port manager
with no copying that has the attributes of files- namely, a third
party manager just as in PIPE:. Then people can safely close them, 
etc. without worrying about giving other people bad pointers.
I am real unhappy with taking the existing port mechanism just 
as is- i think we have got to make this reliable, if only so 
Jerry Pournelle won't flame us.
ron
-- 
ron (rminnich@udel.edu)