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