>>107,112,117
No, wait, you're discussing wrong things.
* I don't have a problem with write blocking until all data was written, in fact I think that's the Right behaviour.
* After some consideration, I think that it should be guaranteed that `read` will return early if there is insufficient data in buffer, because it is necessary for interactive programs to work and is a more or less natural, expected behaviour.
* 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.
Not giving such guarantee is useful because most other stream protocols do not give it either, so not allowing OS to introduce additional fragmentation for pipes means that instead of sending data directly to the tcp/ip driver it should wrap every `writ`ten buffer in a message with length and shit, send that, collect the entire message in a dynamically reallocated buffer on the other side, and only then give it to the program waiting on read.
Giving such guarantee is useless because you have to check if your buffer ends with newline or whatever other delimiter you expect your source to use when read returned sizeof(buffer) anyway, so just check buffer[len-1] always.
Giving such guarantee is harmful because it encourages programmers to assume that lines longer than 8192 or whatever bytes don't real instead of doing the aforementioned check.
* It probably should not be guaranteed that read will never return more data than a single write has written; in other words the OS should be allowed to remove fragmentation when it has enough data available.
This is useful because tcp/ip does this (for performance reasons, which are important to us as well), as far as I know. Not forcing OS to do retarded things to stream pipes over tcp/ip is good.
Having such guarantee is mostly useless, because why don't you play safe and properly search the data for the delimiter
you want, instead of having an unwritten requirement that something earlier in the pipe should split output using that delimiter? The only thing that you can't do otherwise is, well, consume a single line from input, but idk, that actually sounds harmful. That's not how piping should work, in my opinion. You want to send parts of the stream to different program, use xargs or something, that shit is too rarely used and too magical to be allowed to contaminate the core abstraction.