开发者

Can regular file reading benefited from nonblocking-IO?

开发者 https://www.devze.com 2023-02-24 04:00 出处:网络
It seems not to me and I found a l开发者_StackOverflowink that supports my opinion. What do you think?The content of the link you posted is correct.A regular file socket, opened in non-blocking mode,

It seems not to me and I found a l开发者_StackOverflowink that supports my opinion. What do you think?


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.


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.


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.)

0

精彩评论

暂无评论...
验证码 换一张
取 消