Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!agate!ig!uwmcsd1!leah!itsgw!steinmetz!uunet!mcvax!diku!thorinn
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.bugs.sys5
Subject: Re: Re: Is applying ulimit to pipes a bug?
Keywords: ulimit pipe filesystem
Message-ID: <3827@diku.dk>
Date: 20 May 88 20:59:24 GMT
References: <242@twg-ap.UUCP> <244@twg-ap.UUCP> <7928@brl-smoke.ARPA> <11575@mimsy.UUCP>
Organization: DIKU, U of Copenhagen, DK
Lines: 20

In article <11575@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>As it happens, in older Unixes, the `apparent' size of a pipe was reset
>only when the reader caught up with the writer (or something along
>those lines---I never looked at that code, and now my pipes are
>sockets, but a friend says this).  It may be that if the reader is
>perenially 1 block behind the writer, that the pipe eventually reaches
>the ulimit.

I just looked at Edition 6 (Lions): Yes, the apparent size is reset to
zero only when the reader catches up to the writer, but the writer is
blocked when the apparent size reaches 4kB (the `small file' limit).
  Now if someone changed the latter behaviour without changing the former,
and then put in ulimit, the described symptoms might occur -- but think of
it: A pipe allocating and deallocating disk blocks (on the root device!)
somewhere in a doubly indirected block. Stupefying.
  The socket implementation has an advantage here, as it is not bound to a
single linear sequence.
--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcvax!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.