Re: (more) epoll troubles

[Michael Noisternig]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/