Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uflorida!rex!ames!bionet!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Pipe devices in 2.0
Summary: A solution
Keywords: pipe, IPC, ppipc
Message-ID: <1990Jul6.075801.8360@agate.berkeley.edu>
Date: 6 Jul 90 07:58:01 GMT
References: <1453@osupyr.mps.ohio-state.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Organization: University of California, Berkeley
Lines: 74


In posting <1453@osupyr.mps.ohio-state.edu>, Vidhyanath K. Rao
(vkr@osupyr.mps.ohio-state.edu) asks:


 >  device in 2.0?  Specifically, my question is: Can PIPE be made to
[   ^^ Hey.. is the line eater still alive...?! (:-))]
 >  return read packets as soon as a newline is encountered [as CON: will do]
 >  instead of waiting for the buffer to fill up. [I would like to put my
 >  front end on Maple, but it has an input buffer of several hundred bytes;
 >  of course, I don't have the source code ;-^].

Yeah, that IS an annoying feature of PIPE:, isn't it? (Especially as the
1.3 Enhancer manual indicates otherwise...)

There's no option on the PIPE: device (even in 2.0) to change its buffering
(though I don't see any reason why there COULDN'T be), but as it happens
I've just [about?] finished a DOS device that may do exactly what you want.

In practice, it behaves -- and is used -- very like a named pipe, but
there are a couple of significant differences.  For one thing, it does
exactly what you need: data is buffered by PACKET, rather than in a fixed
buffer, so that the reader is woken up the moment any data arrives.

Second, there can be several processes opened for writing to one channel
(though only one reader) -- I've thought maybe I should call it a "Funnel".
The channel stays open as long as ANY process is connected to it (reader
or writer), but by default an EOF (null packet) is sent when the last
current writer closes.  This can be inhibited if you wish (or ignored -- if
you are coding the reader program...).

Either end of the channel can be opened first, but any writing done when
there is no reader is basically thrown away.  (Actually it returns a write
error, but it's amazing how many programs ignore this!)  This could cause
problems if you're expecting pipe-like buffering, so it doesn't entirely
replace the PIPE:.

So what is this device?  Well, [naturally, if you know me!(;-))] it
uses IPCPorts (ppipc.library) as the link between writer and reader.
Basically, for each packet sent to the writer, it posts an IPCMessage
referencing the packet data to its designated port.  Data is NOT copied
at this point.  If a read packet has been posted at the other end, the
data (or as much as there is room for) is copied to the read packet's
buffer, and this is imediately returned.  The write packet is released
by the reply of the IPCMessage, which occurs the moment all data has
been transferred (which could take several reads).

You use it almost exactly as you would a pipe (after you've installed
ppipc.library and IPC-Handler, and Mounted the "IP:" device).  Like:

        run type IP:mychan
        list >IP:mychan

Note the bass-ackwards ordering, because I've assumed these commands
were given to the same shell for example's sake (and read should start
before write).  If I DO want to type the data in practice, I usually
have a separate shell to do it anyway.

[I should say, BTW, for those who know PPIPC, that the handler does use
LoadIPCPort, so a Broker can be triggered by opening the write side, and
then there would be no danger of losing early data]

[Another aside: I was GOING to use 'Search' in my example above -- a
practical example, y'know -- but I just discovered it doesn't accept
input from IP: OR PIPE:!  (Neither device recognizes filesystem type
packets, which apparently 'Search' uses somehow.  Ah well.]

                        +  +  +

Status?  Well, it all seems to work well, but there are a few little
things to be taken care of yet.  Like docs, for instance.  Shouldn't be
too long, I hope.

                                            -- Pete --