On Tue, 14 Jul 2009 08:13:20 +0200 Roland Mainz wrote:
> Garrett D'Amore wrote:
>> Bob Friesenhahn wrote:
>> > On Fri, 10 Jul 2009, Roland Mainz wrote:
> [snip]
>> I agree that we should *not* have the pipe(2) system call change the
>> system default... that would be potentially destructive to many
>> applications, as you note.
>
> BTW: My idea was to make this value a _tuneable_ set-able via
> |setrlimit()|, not changing the system limit (however it may be nice to
> do that for Solaris 3.x/SunOS6.x).
Roland,
According to the standards, PIPE_BUF is a constant for all pipes located
in a given filesystem. So pipes created with pipe() are required to all be
the same size unless you use some interface not defined by the standards.
If you use mkfifo() (and, in the 2008 version of the standard, mkfifoat())
to create pipes (the only difference between a pipe and a FIFO is that a
FIFO has a link in the file hierarchy) in different filesystems (mount
points in the standard; not necessarily filesystem type) pipes created
under different mount points could have different values for PIPE_BUF.
Note that if PIPE_BUF is not a constant for all pipes and FIFOs on a
system, PIPE_BUF must not be #defined in <limits.h>. This
requirement is true no matter how the value of PIPE_BUF changes.
The way in the standard to get the value of PIPE_BUF for a given pipe
or FIFO is to use:
getconf _PC_PIPE_BUF FIFO_pathname
from the shell, or:
pathconf(FIFO_path, _PC_PIPE_BUF);
or:
fpathconf(pipe_or_FIFO_fd, _PC_PIPE_BUF);
in C.
Iff it is no longer true that backing store for a pipe or FIFO is located in
a filesystem (i.e., all pipe and FIFO buffers are only in the kernel with
no backing store on the fifesystem where the pipe or FIFO was created),
you might want to file an interpretation request against the standard.
Among other things you would need to change in the standard would be
to move PIPE_BUF from the Pathname Variable Values section of the
DESCRIPTION of <limits.h> to the Runtime Increaseable Values
section, Making a change like this may break application portability.
Note also that although PIPE_BUF on Solaris systems is 5120, the
standard allows PIPE_BUF to be as low as 512 (as defined by
_POSIX_PIPE_BUF).
Good luck,
Don
PS
The standards conformance tests play lots of games with PIPE_BUF
to verify that the requirements for pipes and FIFOs specified by the
DESCRIPTION of write() (atomicity, non-interleaving output, etc.
depending on whether the fd has O_NONBLOCK set0. From past
experience, be prepared to get lots of failures from the standards
conformance test suites and plan to have someone ready to file
interpretation requests and propose changes to the standards if you
proceed with this proposal. As far as I know, Sun no longer
employs anyone with this activity in their job description.
You may be able to get by by saying that changing the size of a pipe is
a non-standard extension and that it won't affect standards conforming
applications. But, that won't be true if you pass a pipe or open FIFO
to a child process that execs anything expecting standard behavior.
Note that using setrlimit() to set the size of the buffer for all pipes and
FIFOs created by a process and its children after the size change will
require a MANY more changes in the standard than adding a way to
set the value of PIPE_BUF for all pipes created on a particular
filesystem (e.g., a mount option) or a way to change the value of
PIPE_BUF for a pipe or FIFO associated with an open file descriptor.
Trying to add a new parameter to pipe() is EXTREMELY unlikely
to be accepted by The Austin Group's standards committee!
Have you considered adding a new pair of cmd values for fcntl()?
(Perhaps something like F_[GS]ETPBS or
F_[GS]ET_PIPE_BUF_SIZE with the third arg being a pointer to
an object of type off_t?)
If you decide to pursue this, you might note that there may already
be a problem in the standards in this area for STREAMS-based pipes.
If different filesystems have different values for PIPE_BUF, fattach()
could generate unexpected behavior. ;-} This problem would only
have an effect on systems that actually have filesystems with different
values for PIPE_BUF. I don't remember ever seeing a system where
this is the case.
