Is applying ulimit to pipes a bug?

[Lars Henrik Mathiesen]

In article <11575 at mimsy.UUCP> chris at 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.