lkml.org 
[lkml]   [2008]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: unexpected extra pollout events from epoll
[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




\
 
 \ /
  Last update: 2008-10-27 00:15    [W:0.038 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site