Path: utzoo!utgpu!water!watmath!clyde!att!ttrdc!levy From: levy@ttrdc.UUCP (Daniel R. Levy) Newsgroups: comp.bugs.sys5 Subject: Re: Is applying ulimit to pipes a bug? Summary: what version of system V? Keywords: ulimit pipe filesystem Message-ID: <2673@ttrdc.UUCP> Date: 17 May 88 18:19:49 GMT References: <242@twg-ap.UUCP> Organization: AT&T, Skokie, IL Lines: 28 In article <242@twg-ap.UUCP>, dwh@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,!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.