Why having to use non-blocking fd in a edge triggered epoll function?

Question

I read document abount edge triggered epoll function in web as follows:

1. The file descriptor that represents the read side of a pipe (rfd) is registered on the         


        

Answer 1

The idea is to try to completely drain the file descriptor when you have an edge-triggered notification that there is data to be had. So, once epoll() returns, you loop over the read() or write() until it returns -EAGAIN when there is no more data to be had.

If the fd was opened blocking, then this last read() or write() would also block, and you wouldn't have the chance to go back to the epoll() call to wait on the entire set of fds. When opened nonblocking, the last read()/write() does return, and you do have the chance to go back to polling.

This is not so much of a concern when using epoll() in a level-triggered fashion, since in this case epoll() will return immediately if there is any data to be had. So a (pseudocode) loop such as:

while (1) {
  epoll();
  do_read_write();
}

would work, as you're guaranteed to call do_read_write() as long as there is data. When using edge-triggered epoll, there is potential for the notification that new data is available to be missed, if it comes in between the finish of do_read_write() and the next call to epoll().

Answer 2

I guess it's because of the semantics of edge-triggered. The edge-trigger, according to the semantics, will raise another event only once the EAGAIN has been received. In case of blocking sockets there is no EAGAIN. You could have defined it in some other way, but this how Linux defines it. In other words, If you use blocking sockets, you have no idea about when you can safely call epoll_wait.

Answer 3

You must read all or write all the data on epoll's ET mode, because the et mode triggered once after the flag changed. When you have read all data, the thread must be hang if you use the block read or write. So that nonblocking must be used.