Re: Unexpected cascaded epoll behavior - my mistake or kernel bug

[Davide Libenzi <davidel@xmailserver.org>]

On Fri, 23 Jan 2009, Pavel Pisa wrote:

> Hello Davide and all others,
> 
> I have got to implementing yet another event library and I experience
> something strange when level triggered epoll_wait() monitors another
> level triggered epoll set. Top level epoll_wait() return information
> about one event pending. The event points correctly to the monitored
> second level epoll fd, but epoll_wait() on this fd with 0 or small timeout
> returns zero/no events and top level epoll reporting is not reset at this
> point so program enters busy loop. If there are events, they are processed
> correctly.

I'm ashamed to say, I know. It has been reported to me about three months 
ago, I coded patches, but I did not have the time to test them carefully.
The problem is that inside the epoll wakeup callback, we don't know which 
even we got (and we can't call ->poll()). So we add the fd to the 
ready-list and we wake up the waiters. The current code simply does return 
EPOLLIN (from epoll's poll()) if the ready-list is not empty. The problem 
is that the even we received in the epoll callback could have been a 
POLLIN when the fd is waiting for POLLOUT. THis situations gets sorted out 
in epoll_wait(), but inside epoll's poll() only a quick test was used 
(ready-list not empty).
The patch was not exactly a one-liner, so I need a few days to double 
check it and test it. I'll try to do it this w/end.



- Davide