Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45AEE8D4.7030808@haxent.com.br>
Date: Thu, 18 Jan 2007 01:26:12 -0200
From: Davi Arnaut <davi@haxent.com.br>
MIME-Version: 1.0
To: Paul Querna <chip@force-elite.com>
Cc: dev@apr.apache.org
Subject: Re: Bug in epoll
References: <45AD9B05.1090601@force-elite.com>
In-Reply-To: <45AD9B05.1090601@force-elite.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Paul Querna wrote:
> Hey All,
> 
> I am observing a bug in apr_pollset_poll.
> 
..
> 
> To me, the non-kernel programmer, it looks like epoll is only getting
> triggered on the wakeup timer for the timeout, and not returning
> instantly when it has found a socket available for read.  When it
> finally does hit the timeout wakeup, it does notice that there is a
> socket available to read, and returns it, rather than an actual timeout.
> 
> For the short term, I am satisfied with disabling epoll on my builds of
> APR.  I think we should consider disabling epoll by default on APR, if I
> can isolate the bug to a kernel revision.
> 

epoll code hasn't changed much in ages..I would probably blame
apr_memcache code :)

Example:

apr_memcache_multgetp():

..
    rv = apr_pollset_create(&pollset, apr_hash_count(server_queries),
temp_pool, 0);
..
..
    apr_pool_clear(temp_pool);
    apr_pollset_destroy(pollset);

Also there a lot of calls that the returns values are not checked.
Anyway, better double check the apr_memcache code. A full strace log
should help shed some light on the issue.

--
Davi Arnaut