From cb1de8d77d2f25a9002a88a24f13c1944d2e4779 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Thu, 28 Feb 2008 15:54:33 +0000 Subject: [PATCH] Futher refinement of Q9/A9. --- man7/epoll.7 | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/man7/epoll.7 b/man7/epoll.7 index 7ab7b1c79..b847b9ed0 100644 --- a/man7/epoll.7 +++ b/man7/epoll.7 @@ -385,11 +385,18 @@ Receiving an event from .BR epoll_wait (2) should suggest to you that such file descriptor is ready for the requested I/O operation. -You have simply to consider it ready until you receive the next +You must consider it ready until the next (non-blocking) +read/write yields .BR EAGAIN . When and how you will use the file descriptor is entirely up to you. .sp -For stream oriented files (e.g., pipe, FIFO, stream socket), the +For packet/token-oriented files (e.g., datagram socket, +terminal in canonical mode), +the only way to detect the end of the read/write I/O space. +is to continue to read/write until +.BR EAGAIN . +.sp +For stream-oriented files (e.g., pipe, FIFO, stream socket), the condition that the read/write I/O space is exhausted can also be detected by checking the amount of data read from / written to the target file descriptor. @@ -402,11 +409,8 @@ can be sure of having exhausted the read I/O space for the file descriptor. The same is true when writing using .BR write (2). -.sp -For packet/token oriented files (e.g., datagram socket, -terminal in canonical mode), you need to continue to read/write until -.BR EAGAIN , -in order to detect the end of the read/write I/O space. +(Avoid this latter technique if you cannot guarantee that +the monitored file descriptor always refers to a stream-oriented file.) .SS Possible Pitfalls and Ways to Avoid Them .TP .B o Starvation (edge-triggered)