Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!hoptoad!academ!uhnix1!sugar!peter
From: peter@sugar.UUCP (Peter DaSilva)
Newsgroups: comp.sys.amiga
Subject: Re: MCC pipes
Message-ID: <185@sugar.UUCP>
Date: Tue, 16-Jun-87 08:32:39 EDT
Article-I.D.: sugar.185
Posted: Tue Jun 16 08:32:39 1987
Date-Received: Thu, 25-Jun-87 00:54:13 EDT
References: <8706120539.AA16159@cory.Berkeley.EDU>
Organization: Sugar Land UNIX - Houston, TX
Lines: 61
Summary: Just going by the docs.

In article <8706120539.AA16159@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> >You create a named pipe with a mknod call. As a special case anyone can do
> >this. The pipe is therefore just another special file. You can open it
> >and write to it just like a file. You can open it and read from it similarly.
> >Unlike PIPE: pipes, a reader doesn't hang on opening... it hangs on a read.
> >Similarly a writer doesn't hang: it can just write its bytes and get out of
> >there without waiting for a reader to show up. You also don't hang on close
> >waiting for your coconspiritor to finish. Otherwise it's pretty much the same.
> >
> >It would be nice if the MCC PIPE: would handle more packets. For example,
> >Examine and ExNext.
> 
> 	You are, fortunetly, wrong. I wrote PIPE:, and it neither blocks
> on Open() nor blocks on Write().  In fact, I certainly hope MCC pipes have
> a provision for non-infinite buffer sizes, or they are useless to me.  Perhaps
> you are refering to a very early version of my PIPE:?

I don't know what version I'm talking about. Did you write the PIPE: device
in the MCC toolkit, as well as the one whose source is floating around (that
is, are they the same program)? It may well be a very early version that I'm
using here. Let me check:

The posted date is 6th Feb 1987. The buffer size is stated to be 4K. It does
direct write-through when writing to a pending read (nice touch). The source
contains the notation that if you open-write<4K bytes-close, the close will
wait until a reader opens the pipe. That's what I mean by "waiting for your
co-conspiritor to finish".

> 	Specifically, you can specify the buffer size for PIPE: pipes easily
> enough:  'pipe:name/b#'.  If you want an infinite buffer size (writer NEVER
> blocks), then 'pipe:name/n' suffices.  Without any options, the pipe uses a
> 4K buffer.

There doesn't seem to be any provision for this.

> 	Now you may ask, 'why not just make it use infinite buffer sizes
> as a default'??  That's an easy question to answer.  By example I will 

Nope, I didn't ask this one. It's pretty obvious that yanking all of memory
in a multitasking system isn't always appropriate. I'm not sure I would use
the infinite buffer size feature at all.

> 	VD0: is quite a bit more than the measily 2.5Meg I've got.  I can use
> 	an infinite buffer size for the second PIPE: because Restore can
> 	read data much faster than the decompressor can decompress it.  

But because of this, the pipe will always be almost empty, so you might as well
give it a 4K buffer size as well. It might be noted here that the UNIX pipes
have a 4K buffer size.

Now, a question and a request:

Does your new PIPE: support the packets Examine and ExNext use? If so, then you
could just "dir pipe:" to get a list of active pipes, right?

The request: I want to use your PIPE: device as the skeleton for an improved
console device. May I? How would I use it with Aztec (compatibility mode for
sure, right)? Can I call Intuition from a device (opening windows, etc) or do
I have to handcraft windows from the lower level primitives? I assume the
former, but I've visited the Guru enough to know how often my assumptions are
unwarranted.