Re: unexpected extra pollout events from epoll

[Paul P <ppak_98@yahoo.com>]

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

Let's say I'm sending a large buffer of data and I arm the fd to epollin|epollout (I'm adding an epollin flag because a message could come in while I'm sending)

If an event gets triggered on an fd, then I have no way of knowing if the event is from the socket being available to send data or if there is data waiting to be received since the epollin|epollout flag could be either one.  So what am I to do when I get an event?

Are you saying that I can't do sending and receiving simultaneously with epoll?  If that's the case, then is everyone simply setting the epollout flag when sending and ignoring the possibility of data coming in while data is being sent?

I didn't want to have to manually set fd's with epoll_ctl, but now I guess the epoll_one_shot flag makes more sense.  

Paul