valke@cs.vu.nl (Valkenburg Peter) (03/22/88)
Hello there, first of all, sorry if the following issue has been discussed before, I haven't been reading this newsgroup for some time now. I am writing a package for named pipes on 4.1bsd (I know, system V has it built-in, but we don't), and while testing it came across a very weird feature (bug in my opinion) of pipe(2). Pipe is supposed to suspend writes that would fill it up beyond 4096 bytes, until a read is issued on the other end, shrinking it below this limit. However, this only works if the pipe has a size larger or equal to 4096 bytes before the over-productive write is issued. Meaning that in pipe (fdp); ... write (fdp [1], buf, 4096); write (fdp [1], buf, 1); the second write will be suspended until the pipe is read, while in pipe (fdp); ... write (fdp [1], buf, 1); write (fdp [1], buf, 4096); it will NOT! The size of the pipe as given by fstat(2) in the second case is 4097, and read (fdp [0], buf, 4097); will pick up 4097 bytes. On the other hand, write (fdp [1], buf, 4097); will always block until someone picks up some data (and it should). Is there any good reason for this?? I admit that it could be considered a nice feature to be able to stuff more than the sacred number of 4096 bytes in a pipe, but this just doesn't seem very consistent. Of course, in normal applications no one will notice this funny behaviour, because the limit of what you can write without reading is still 4095 + 4096. Moreover, most applications read/write in log2 fractions of 4096 (1, 512, 1024, whatever), thus blocking on pipes when they contain precisely 4096 bytes. Cat(1) is an example of this. I'm very curious to know why pipe(2) was implemented this way (lazy systems programmer?, some weird program needs this?, nobody cares anyway?) and would be happy get some responses. Thanks in advance, Peter Valkenburg (...!mcvax!botter!ark!valke).