Weird pipe(2) behaviour

[Valkenburg Peter]

		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).