Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

considered harmful

Name: Anonymous 2013-02-25 6:06

http://harmful.cat-v.org/software/
>2013
>using harmful software

Name: Anonymous 2013-03-03 11:01

>>119
So, what's the problem?

* I don't have a problem with write blocking until all data was written, in fact I think that's the Right behaviour.
Okay, good. This is what plan9 does specifically, and what probably all serious UNIX operating systems normally do, even though POSIX allows for early return.

* 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.
This is what read(2) always has done. It fills the buffer with bytes read from the file descriptor, and if it's less than the size of the buffer, either you've reached end-of-file, or you're reading from a pipe, terminal or socket. However, read(2) might block until there's at least something to read, which might happen when the writing process block buffers its output. If you want to check whether reading will block, poll the file or perform an explicit nonblocking read (which might return nothing).

* 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.
There is no corresponding write to a read. You don't write(2) into a read(2), you write to file descriptors and read from file descriptors. Once written to a file descriptor there's no information whether it was written in one call to write(2) or ten.

Nobody does what you are criticizing, but if they did, you'd be correct in that it'd be harmful. But this is not what the "one write" that read(1) promises is about. read(1) will write once, one line, which will be read in full and parsed again for newline on the receiving end. Whether this is read with one call to read(2) or ten doesn't matter. If you run read(1) with the option of reading two lines, it might write both before any single line has even been read.

* 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.
Yes, of course, and nobody does that. Again, there's no mapping between individual calls to write(2) and read(2), you only read and write to file descriptors, usually asynchronously.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List