8

It seems not to me and I found a link that supports my opinion. What do you think?

Cheng
  • 4,816
  • 4
  • 41
  • 44

3 Answers3

10

The content of the link you posted is correct. A regular file socket, opened in non-blocking mode, will always be "ready" for reading; when you actually try to read it, blocking (or more accurately as your source points out, sleeping) will occur until the operation can succeed.

In any case, I think your source needs some sedatives. One angry person, that is.

kqnr
  • 3,596
  • 19
  • 17
5

I've been digging into this quite heavily for the past few hours and can attest that the author of the link you cited is correct. However, the appears to be "better" (using that term very loosely) support for non-blocking IO against regular files in native Linux Kernel for v2.6+. The "libaio" package contains a library that exposes the functionality offered by the kernel, but it has some caveats about the different types of file systems which are supported and it's not portable to anything outside of Linux 2.6+.

And here's another good article on the subject.

Jonathan Oliver
  • 5,207
  • 32
  • 31
2

You're correct that nonblocking mode has no benefit for regular files, and is not allowed to. It would be nice if there were a secondary flag that could be set, along with O_NONBLOCK, to change this, but due to the way cache and virtual memory work, it's actually not an easy task to define what correct "non-blocking" behavior for ordinary files would mean. Certainly there would be race conditions unless you allowed programs to lock memory associated with the file. (In fact, one way to implement a sort of non-sleeping IO for ordinary files would be to mmap the file and mlock the map. After that, on any reasonable implementation, read and write would never sleep as long as the file offset and buffer size remained within the bounds of the mapped region.)

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Regarding mmap()... it would be blocking to turn the file non-blocking... ;-) – Robert Siemer Nov 18 '13 at 07:06
  • 3
    It isn't *that* difficult to define what nonblocking behavior could mean for ordinary files. The kernel would have to signal the file as ready to read when the data requested by the next `read` is in the page cache. If it's gone by then, the kernel could just return `EWOULDBLOCK` (and add the requested range to some mandatory prefetch and when it's available the file will be set ready to read and so on). It wouldn't be a race condition if everyone is implemented right, but there would be the possibility of a livelock if many processes keep trying to outread eachother and none makes progress. – DepressedDaniel Mar 14 '17 at 02:08