lkml.org 
[lkml]   [2008]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: (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.


    \
     
     \ /
      Last update: 2008-09-01 20:33    [W:0.024 / U:32.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site