Subject: Re: bi-directional pipes?
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 02/04/2003 18:20:33
[ On Tuesday, February 4, 2003 at 14:25:07 (-0500), Andrew Brown wrote: ]
> Subject: Re: bi-directional pipes?
>
> >> Feel free to further simplify the structures. We definitely don't
> >> want to ever support bi-directional pipes. It's unncecessary
> >> memory and CPU waste.
> >...
> >
> >David Laight's concern about compatability with other very widely used
> >systems that support bi-directional pipes is also quite valid.
>
> what systems? i tried, at one point, to find one, but failed.
As David said, SVR4 and all its many derivatives (i.e. most commercial
Unix variants), including of course all the many Solaris releases, such
as SunOS-5.6:
NAME
pipe - create an interprocess channel
SYNOPSIS
#include <unistd.h>
int pipe(int fildes[2]);
DESCRIPTION
pipe() creates an I/O mechanism called a pipe and returns
two file descriptors, fildes[0] and fildes[1]. The files
associated with fildes[0] and fildes[1] are streams and are
both opened for reading and writing. The O_NDELAY and
O_NONBLOCK flags are cleared.
[[ .... ]]
NOTES
Since a pipe is bi-directional, there are two separate flows
of data. Therefore, the size (st_size) returned by a call
to fstat () with argument fildes[0] or fildes[1] is the
number of bytes available for reading from fildes[0] or
fildes[1] respectively. Previously, the size (st_size)
returned by a call to fstat() with argument fildes[1] (the
write-end) was the number of bytes available for reading
from fildes[0] (the read-end).
In the commercial UNIX world it's been this way for many many years now.
I would not be suprised at all if there were not many applications
depending on this well documented behaviour.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>