Re: epoll with ONESHOT possibly fails to deliver events

[Andreas Voellmy]

Hi Eric, 

Thanks again for looking at our bug report. I agree with Jason's comments: the bug occurs independently of the socketCheck function; this function waits long enough for the server to stop serving any more requests and then checks the sockets to find out which ones still have data (and therefore should be served).  But I like your suggestion, so I updated the code to use ioctl rather than recv in socketCheck. As we expected, the bug still occurs. 

Cheers, 
Andi

On Dec 20, 2012, at 5:25 PM, "Junchang(Jason) Wang" <junchang.wang@xxxxxxxx> wrote:

> On Thu, Dec 20, 2012 at 4:32 PM, Eric Wong <normalperson@xxxxxxxx> wrote:
>> Andreas Voellmy <andreas.voellmy@xxxxxxxx> wrote:
>>> I wrote a C program that behaves similar to my original program and
>>> triggers the bug. The bug only arises when I use enough cores and
>>> threads (about 16). The program is here:
>>> https://github.com/AndreasVoellmy/epollbug/blob/master/epollbug.c
>> 
>> I finally took a closer look at your code.   I think your socketCheck()
>> thread is draining socket and causing the normal threads to miss
>> events.
>> 
> 
> Hi Wong,
> 
> Thank you so much for responses. But I think you probably
> misunderstood socketCheck() which we use at the end of the program to
> check whether the bug has occurred (by checking whether some data
> remains in the sockets). Please note there's a sleep(10) (line 237) at
> the very beginning of socketCheck(). In other words, we can guarantee
> recv() (line 239) doesn't execute when the normal threads are running.
> 
> We still believe this is a bug in epoll system even though we can't
> prove that so far. Both Andi and I are very interested in this problem
> and helping you experts solve this it. Just let us know if we can
> help.
> 
> 
> Thanks.
> 
>> Use the FIONREAD ioctl() instead to get unread bytes instead of recv().
>> If you want to recv() without draining the socket, you can also use
>> the MSG_PEEK flag.

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