Why use non-blocking fd in an edge-called epoll function?
I read the epoll function that launched the front on the internet like this:
1. The file descriptor that represents the read side of a pipe (rfd) is registered on the epoll instance.
2. A pipe writer writes 2 kB of data on the write side of the pipe.
3. A call to epoll_wait(2) is done that will return rfd as a ready file descriptor.
4. The pipe reader reads 1 kB of data from rfd.
5. A call to epoll_wait(2) is done.
.......
.......
The suggested way to use epoll as an interface (EPOLLET) is: i) Use non-blocking file descriptors ii) Calling epoll_wait on a read-only (2) or write (2) event returns EAGAIN.
I figured 2, but couldn't figure out why non-blocking file descriptors are used.
Can anyone explain the reason for using non-blocking file descriptors? Why are all blocking file descriptors in the layer-called epoll function?
source to share
The idea is to try to completely merge the file descriptor when you have an edge-related notification of data availability. So, as soon as it epoll()
returns, you iterate over read()
or write()
until you return -EAGAIN
when there is no more data.
If fd was blocked, then the latter will read()
either write()
block, and you will not be able to return to the call epoll()
to wait for the entire set of fds. On opening non-blocking, the last read()
/ is write()
returned and you have the option to return to the poll.
This is not so important when used epoll()
when starting the level, as it epoll()
will return immediately if there is any data. So a loop (pseudocode) like:
while (1) {
epoll();
do_read_write();
}
will work as you are guaranteed to call do_read_write()
as long as there is data. When using an epoxy effect with a boundary edge, there is a possibility of notification that new data may be skipped if it is between completion do_read_write()
and the next call epoll()
.
source to share
I guess it has to do with the semantics of edge triggering. The trigger threshold, according to semantics, will raise another event only after receiving EAGAIN. There is no EAGAIN in case of blocking sockets. You might have defined it in some other way, but this is how Linux defines it. In other words, if you are using blocking sockets, you do not know when you can safely call epoll_wait.
source to share