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>