Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!cit-vax!elroy!mahendo!jplgodo!wlbr!scgvaxd!stb!michael
From: michael@stb.UUCP (Michael)
Newsgroups: comp.sys.amiga
Subject: Re: PIPE:... should it buffer at all?
Message-ID: <92@stb.UUCP>
Date: Mon, 31-Aug-87 11:18:21 EDT
Article-I.D.: stb.92
Posted: Mon Aug 31 11:18:21 1987
Date-Received: Sat, 5-Sep-87 04:25:19 EDT
References: <571@sugar.UUCP>
Reply-To: michael@stb.UUCP (Michael)
Organization: STB BBS, LA, CA, USA, 90402, (213) 459-7231
Lines: 22
Keywords: PIPE: buffer UNIX pipes

In article <571@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
>It occurred to me that the most efficient way to handle PIPE: is to use the
>writer's buffer to hold the data while waiting for the reader. This, of course,
>would make all requests wait until the reader is ready... but Amiga PIPE:s
>don't act like UNIX pipes anyway. It would allow any buffer size to be
>transferred as an atomic operation.

Please, no. We already have any size atomic operations--the order of the
operations are specified by the order that the messages come in.

>Alternatively, how about making PIPE: act like the UNIX pipe? That is, you
>can open it and write as much as you please without waiting until you fill
>it up. You can have multiple writers but only one reader. The pipe hangs
>around as long as a single writer *or* reader wants it. And finally you can
>reopen it without losing data.

Gee, thats how I thought PIPE: worked. Besides, I like P:, which can have
multiple readers.

-- 
: Michael Gersten		seismo!scgvaxd!stb!michael
: Copy protection? Just say Pirate! (if its worth piratill t