Is applying ulimit to pipes a bug?

[Daniel R. Levy]

In article <242 at twg-ap.UUCP>, dwh at twg-ap.UUCP (Dave Hamaker) writes:
# I find myself often needing/wanting to put filters before and/or after raw
# devices and network connections.  Often, the volume of data involved exceeds
# the ulimit file size controls.  If I don't raise the ulimit, the pipes fail.
# This doesn't make sense to me, as pipes do not accumulate resources in the
# same kind of way as disk files: an out-of-control disk file can use up all
# the disk space; an out-of-control pipe consumes only renewable resources.
# The ulimit documentation is inclusive on the matter; in fact, it sounds
# confused.  If you ask me, I smell a bug of omission; the pipe type just rode
# along with the file type during ulimit implementation, without much thought
# about it.
# The Wollongong Group

What VERSION of System V are you using, on what machine?  The only pipe-related
ulimit problem I've noticed here (ttrdc ttrdc 2.0v3 1208 3B-20S) is if I make
the ulimit so ridiculously small (like 9) that the ulimit is smaller then the
pipe's buffering capacity (5120 bytes).  In this event a write larger than the
ulimit indeed fails with EFBIG.  I suppose you could call that a bug, albeit
a rather unlikely bug.  If I make the ulimit larger than the pipe's buffering
capacity (even 11) then I can call write() with as much as I please (1
megabyte? no problem, it works) to a pipe.

(I just tried it again on a 3B2, SVR3.1.  Same results.)
-- 
|------------Dan Levy------------|  Path: ihnp4,<most AT&T machines>!ttrdc!levy
|              AT&T              |  Weinberg's Principle:  An expert is a
|       Data Systems Group       |  person who avoids the small errors while
|--------Skokie, Illinois--------|  sweeping on to the grand fallacy.