* Non-blocking filesystem calls do not in fact work on files. If you think about it for a minute this makes sense. Network data is flowing in to you asyncrono

* Non-blocking filesystem calls do not in fact work on files. If you think about it for a minute this makes sense. Network data is flowing in to you asyncronously, it will show up if you don't do anything (and trigger poll). But you have to request to read a file to make the OS make the disk go get it. This is why the async read model works for disk files where the poll/read model doesn't; a disk file is always readable as the data is already there. In Linux in particular the kernel does not (I think, I may be getting the explanation wrong) have a wait queue for page faults, it can only block the faulting process, so you can't do async (non-blocking) cached file I/O at all. * It is not well documented in man pages. It's a relatively well-known problem if you google for it. * The situation for traditional non-blocking reads of disk files has persisted because it is unsolvable in general, poll/read just doesn't work for for reasons described above. You need async read/write, which Linux in particular does not have good support for (see above regarding cached reads). I think the situation on the BSDs may be better, but I'm not sure. There's a number of articles in the kernel section on LWN discussing async I/O that may be enlightening if you want to know more about what's been done here. (http://lwn.net/Kernel/Index/#Asynchronous_IO http://lwn.net/Kernel/Index/#Asynchronous_IO)