🚀 go-pugleaf

In article <7543@agate.BERKELEY.EDU> ( Pete Goodeve ) writes:
>[This is a response to an article in comp.sys.amiga.tech.  Because of the
[Aren't 200 articles as good as 200 'yes' votes?]

> 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.

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
library copies them to a buffer (preallocated) and signals who ever 
you sent it to. Or you can allocate a buffer with "GetIPCBuffer()" 
and save the allocation step. What this buys you is that, a) There are
no longer in resources that the task has to free they are all "owned"
by the library. Thus sudden death syndrome does not involve a loss of
memory. Second, if there was an MMU in there both tasks could map the
buffer pool as shared memory and not worry about address mismatches.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.