Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 47040 invoked from network); 8 Jul 2004 07:32:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 8 Jul 2004 07:32:43 -0000 Received: (qmail 45768 invoked by uid 500); 8 Jul 2004 07:32:41 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 45733 invoked by uid 500); 8 Jul 2004 07:32:41 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 45719 invoked by uid 99); 8 Jul 2004 07:32:41 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Date: Thu, 8 Jul 2004 08:32:36 +0100 From: Joe Orton To: dev@apr.apache.org Subject: Re: cvs commit: apr configure.in Message-ID: <20040708073236.GA31249@redhat.com> Mail-Followup-To: dev@apr.apache.org References: <20040707074012.6267.qmail@minotaur.apache.org> <2D2E58633C24FA2899583035@st-augustin.ics.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2D2E58633C24FA2899583035@st-augustin.ics.uci.edu> User-Agent: Mutt/1.4.1i X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Thu, Jul 08, 2004 at 12:04:48AM -0700, Justin Erenkrantz wrote: > --On Wednesday, July 7, 2004 7:40 AM +0000 jorton@apache.org wrote: > > >jorton 2004/07/07 00:40:12 > > > > Modified: poll/unix poll.c > > . configure.in > > Log: > > * poll/unix/poll.c (backend_cleanup): Only define if using epoll/kqueue. > > (apr_pollset_destroy): Only run cleanup if using epoll/kqueue. > > (apr_pollset_add): Fix warning for ye olde platforms still using poll(). > > I changed this from Paul's patch on purpose. Why shouldn't we always > define the cleanup even if we don't have kqueue or epoll? Since we know the cleanup does nothing, defining it unnecessarily wastes both a few bytes of code size and a few cycles at run-time. e.g. since the cleanup is never registered for the non-epoll/kqueue case, running apr_pool_cleanup_destroy() will iterate over the whole cleanup list looking for it if apr_poll_destroy() is called. > If we add Solaris's /dev/poll, we'd need a cleanup. I see only the > fallback implementation perhaps not needing it - almost any real > implementation would. I thought doing it your way makes the code a > lot less clean. The "unreal?" poll/select implementations will be used on the majority of APR platforms and do *not* currently require a cleanup, no "perhaps" about it. This is just a minor optimisation with minor cleanliness cost for the majority of platforms, I don't think it's a big deal. joe