>>121
* It must not be guaranteed that read will never return less data than the corresponding write has written; in other words the OS should be allowed to introduce additional fragmentation.
Nobody does what you are criticizing, but if they did, you'd be correct in that it'd be harmful.
read(1) will write once, one line, which will be read in full and parsed again for newline on the receiving end.
If the OS is allowed to introduce fragmentation, then when you execute
read <8k_char_line.txt | myprogram, and the pipe actually pipes data through a network socket, then `myprogram` will receive an 8k character line produced by a single write(2) by read(1) in 5 or so 1400 byte reads(2), even if it passes an 8k buffer to it.
This is sane behaviour.
Plan9 documentation strongly implies that Plan9 is guaranteed to implement insane behaviour, where upon execution of write(2) by read(1) the OS will actually send the buffer as a message, with a header saying that it's 8k characters long, and on the other end Plan9 will patiently wait until it gets all data, dynamically reallocating the rcv buffer, and only then will allow `myprogram` to read(2) from it, and will return the entire buffer at once if `myprogram` supplies a sufficiently large buffer of its own.
This is insane behaviour.
http://swtch.com/usr/local/plan9/src/cmd/read.c strongly suggests that the documentation is correctly documenting the insanity of the approach, otherwise read(1) could use a static buffer just like cat(1) and split the output across several writes(2), because why not if the OS is allowed to do that anyway?