Subject: Re: bi-directional pipes?
To: NetBSD Kernel Technical Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
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
pipe - create an interprocess channel
int pipe(int fildes);
pipe() creates an I/O mechanism called a pipe and returns
two file descriptors, fildes and fildes. The files
associated with fildes and fildes are streams and are
both opened for reading and writing. The O_NDELAY and
O_NONBLOCK flags are cleared.
[[ .... ]]
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 or fildes is the
number of bytes available for reading from fildes or
fildes respectively. Previously, the size (st_size)
returned by a call to fstat() with argument fildes (the
write-end) was the number of bytes available for reading
from fildes (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; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>