Re: unexpected extra pollout events from epoll

[Davide Libenzi]

[Can you try to trim lines at 80 chars or so?]


On Sun, 26 Oct 2008, Paul P wrote:

> > After that, via epoll_wait(), f_op->poll() is called to get the status 
> > of  the file, and since POLLIN|POLLOUT is returned (and since you're 
> > listening for EPOLLIN|EPOLLOUT), that gets reported back to you. The 
> > POLLOUT event, by meaning a buffer-full->buffer-avail transition, did 
> > not really happen, but since POLLOUT is true, that gets reported back 
> > too.
> 
> Ok, so make sure I understand you correctly, you're saying that 
> currently the kernel doesn't have awareness of the difference between 
> EPOLLIN and EPOLLOUT events because at the time of the event, both 
> EPOLLIN/EPOLLOUT are returned from the kernel and that at least for the 
> near term that's not going to change.  At some point, we can expect the 
> EPOLLOUT to give the correct event, but not till later than .28.

The kernel knows the difference between EPOLLIN and EPOLLOUT, of course. 
At the moment though, such condition is not reported during wakeups, and 
this is what is going to be changing.



> > The best way to do it ATM, is to wait for POLLOUT only when
> > really needed.
> 
> I'm a little unclear how to do this.  If I set the epoll_wait call to 
> wait for just epollin events, that's fine.  But when I send a large 
> buffer of data and use epoll_ctl to look for epollin|epollout events, 
> don't I have the same problem?  

You do that by writing data until it's finished, or you get EAGAIN. If you 
get EAGAIN, you listen for EPOLLOUT.
Reading is same, but you'd wait for EPOLLIN.



- Davide


--
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/