From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755816Ab2LNAPI (ORCPT ); Thu, 13 Dec 2012 19:15:08 -0500 Received: from atl.turmel.org ([74.117.157.138]:51248 "EHLO atl.turmel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753579Ab2LNAPG (ORCPT ); Thu, 13 Dec 2012 19:15:06 -0500 X-Greylist: delayed 386 seconds by postgrey-1.27 at vger.kernel.org; Thu, 13 Dec 2012 19:15:06 EST Message-ID: <50CA6F86.30608@turmel.org> Date: Thu, 13 Dec 2012 19:15:02 -0500 From: Phil Turmel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121103 Thunderbird/16.0.1 MIME-Version: 1.0 To: Eric Wong CC: Andreas Voellmy , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: epoll with ONESHOT possibly fails to deliver events References: <20121213093242.GA25436@dcvr.yhbt.net> <50CA6E04.1070105@turmel.org> In-Reply-To: <50CA6E04.1070105@turmel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/13/2012 07:08 PM, Phil Turmel wrote: > On 12/13/2012 04:32 AM, Eric Wong wrote: >> Andreas Voellmy wrote: > > [trim /] > >>>> Another thread, distinct from all of the threads serving particular >>>> sockets, is perfoming epoll_wait calls. When sockets are returned as >>>> being ready from an epoll_wait call, the thread signals to the >>>> condition variable for the socket. >> >> Perhaps there is a bug in the way your epoll_wait thread >> uses the condition variable to notify other threads? > > Have you considered the possibility that data is arriving between > epoll_ctl and pthread_cond_wait ? If your monitoring thread returns > from epoll_wait within this race window, it will call > pthread_cond_signal while the first thread is not yet waiting for it. > With the one-shot flag, the next iteration of epoll_wait won't see that > socket's new data. Let me clarify: The read thread must perform the epoll_ctl between pthread_mutex_lock and pthread_cond_wait, while the monitoring thread must hold the mutex lock when signaling. pthread_cond_signal and pthread_cond_broadcast don't require the caller to hold the mutex in general, but your app needs it. Phil