Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem is in what concepts are being considered "the same" when mapping two mostly-dissimilar things (a socket or pipe, vs a file).

poll(), select() et al don't define "readable" as meaning "a byte of data is available". They define it as "read() will not block".

When you read to the end of a file, read() returns "". This is the same as when you try to read from a closed socket. Conceptually, they are linking the concepts of "EOF" and "closed", not the concepts of "EOF" and "waiting for data". And indeed, if you call poll() on a socket that has been closed on the remote end, you will find it is "readable".

Ultimately, regular files just were never intended to be used as pipes. The abstractions just weren't chosen to work in that way.



> poll(), select() et al don't define "readable" as meaning "a byte of data is available". They define it as "read() will not block".

If that were true, poll() wouldn't return read-ready on a file-based fd until the data was actually sitting in buffers. After all, that's the only way to guarantee it won't block. That would actually be a useful semantic.

But what actually happens is that poll() on a file-based fd is basically a no-op that always returns true immediately, AFAIK. Someone could pull the disk drive cable before you actually call read(), in which case read() will indeed block, forever.

The existing semantic is useless. What argument is there in favor of a useless semantic?

This semantic wouldn't solve the "tail -f" problem, but at least it would be useful: http://cr.yp.to/unix/asyncdisk.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: