Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!ucsd!ucbvax!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Pipe devices in 2.0
Keywords: pipe, IPC, ppipc, tank, tee
Message-ID: <1990Jul7.054651.4404@agate.berkeley.edu>
Date: 7 Jul 90 05:46:51 GMT
Expires: 'tank' possible too
References: <1453@osupyr.mps.ohio-state.edu> <1990Jul6.075801.8360@agate.berkeley.edu> <6003@sugar.hackercorp.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Organization: University of California, Berkeley
Lines: 69


Responding to my posting on the "IP:" device "funnel",
Peter da Silva <peter@sugar.hackercorp.com> remarks:
(message <6003@sugar.hackercorp.com>)

 > Pity.

 > What I really want to see is a "tank": you write "things" into it, each read
 > returns a "thing" as written. If there are no writers, it returns EOF only
 > after all the "things" are read. Sort of like a terminal in canonical mode,
 > in UNIX.

Yeah -- me too.  Another mechanism I want badly is a "tee".  But, for both
of them, why not?  Remember our philosophy of PPIPC... way back when...(:-))
It's purpose is to allow plugging together fairly small modules that
combine to do just what you want.

It would be possible to do either with some variant on the IP: handler,
but as communication is via IPCPorts I'd much rather drop another little
module in the chain, as:

        tank inp outp
        run list >IP:inp
        type IP:outp

There's no reason one utility couldn't do both jobs, actually.  ["Tank-Tee"?
-- Nahh, sounds too much like summer clothing...]

        tank inp out1 out2 out3...

The module would simply make copies of each incoming IPCMessage and
its data, and post them to each of its output channels, returning the
original immediately.  You'd have to do something about the problem of
absent reader processes, so data wouldn't get lost.  Probably the simplest
is for 'tank' to set the LOADING flag in each of its target ports (if they
aren't served already), so that the posted messages get queued until the
server actually arrives.

On the other hand you also have to do something to prevent the tank -- i.e.
memory -- overflowing!  If no server ever showed up, messages could keep
getting tacked on to the port.  I suggest that when you invoke the program
you could set a limit (with some default) on the maximum number of
outstanding messages.  This would be quite easy for the tank because it
expects each message it posts to be replied eventually.  It would block its
input port (which would also block the sending process if it was via IP:),
or could even return an error.  You would also have to arrange for it to
"scavenge" all messages hanging on "dead" ports when it was finally closed.

                            - - - -

There were a couple of things I forgot in the first posting.  One has
fairly well just been covered: these are IPCPorts, so ANY equipped program
-- not just another IP: device -- can communicate with an IP: channel.
The format of the IPCMessages has been kept as generic as possible, and
of course will be public.  (And for those who don't know PPIPC, messages
are "self-identifying", so it'd be hard to confuse, except maliciously.)

Second, althoguh I stressed that you can have multiple writers, there is
also a "exclusive access" option (which probably needs improvement).

Finally, the device is unusual in that you can specify both in and out
channel names at once.  This makes it possible to start up a windowless
shell to handle command requests from another process:

        newshell IP:inchan/outchan

I think it may be useful.

                                        -- Pete --