Hacker News new | ask | show | jobs
by ajross 5999 days ago
No, it's the specified behavior of a Unix pipe or socket[1]. If you want it not to block, you should set the O_NONBLOCK flag using fcntl(). Being "write ready" just means that it can take at least one byte in a buffer; it can't possibly be a promise not to block if you feed it a 2G buffer.

[1] But not disk files. Local disk storage isn't considered "blocking" if it simply needs to do a disk seek before returning the data. Most unix geeks end up finding this out experimentally at some point in their careers and using strong language. No, I don't know what they were thinking either...
2 comments
haberman 5998 days ago
In the SuS description of poll(), it says that POLLOUT means "Normal data may be written without blocking." However it does not say how much data. It is unexpected that a write() call would block instead of returning a short count; for example, if you feed it a 2G buffer, it could return 4096 indicating that only 4k of the 2G was actually written.
link
ajross 5998 days ago
It could, but it doesn't and never has. The standard was written to admit a broader set of behavior than real systems actually implement. And in this case, there's absolutely nothing "surprising" to my eyes about a blocking (!) socket blocking on overflow.

Again: there is already a mechanism in place to support non-blocking behavior, and it's not this one.

link
neilc 5998 days ago
If you want it not to block, you should set the O_NONBLOCK flag using fcntl().

Certainly, I had assumed that the OP was talking about poll over non-blocking pipes.

link