Messages in this thread |  | | | Date | Mon, 01 Sep 2008 20:29:02 +0200 | | From | Michael Noisternig <> | | Subject | Re: (more) epoll troubles |
| |
Robert Hancock schrieb: > Robert Hancock wrote: >> Michael Noisternig wrote: >>> Hello, >>> >>> and sorry again if this is the wrong place to ask (again, please hint >>> to me to an appropriate place to ask in that case). >>> >>> After experimenting with epoll edge-triggered mode I am clueless why >>> on a few occassions I seem to not get any input notification despite >>> data is available. >>> >>> In detail: I have set up sockets with epoll events >>> EPOLLET|EPOLLRDHUP|EPOLLIN. When I get EPOLLIN for a socket, I read() >>> as long as I get what I asked for, i.e. whenever read() returns >>> either EAGAIN or less data than I asked for I take this as indication >>> that I must wait for another EPOLLIN notification. However, this does >>> not seem to work always. >>> >>> Here is some log from my program: >>> >>> 0x9e6b8a8: read not avail (1460/2048 read) >>> i.e. tried to read 2048 bytes, got 1460 -> assume must wait for >>> EPOLLIN for more data to read >>> (note that the fd is always in the epoll set with >>> EPOLLET|EPOLLRDHUP|EPOLLIN) >> >> It would likely be better to always continue trying to read until >> EAGAIN is returned, even if the read returned less than the requested >> amount, as implied here: >> >> http://linux.die.net/man/7/epoll >> >> "The function do_use_fd() uses the new ready file descriptor until >> EAGAIN is returned by either read(2) or write(2). An event driven >> state machine application should, after having received EAGAIN, record >> its current state so that at the next call to do_use_fd() it will >> continue to read(2) or write(2) from where it stopped before. " > > Though, this is somewhat contradicted by the FAQ section: > > "the condition that the read/write I/O space is exhausted can be > detected by checking the amount of data read/write from/to the target > file descriptor. For example, if you call read(2) by asking to read a > certain amount of data and read(2) returns a lower number of bytes, you > can be sure to have exhausted the read I/O space for such file descriptor."
Yes, exactly. I don't know what is causing the problem I'm experiencing. Especially as it happens rather infrequently.
|  |