Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Bill Stoddard" <bill@wstoddard.com>
To: "APR Development List" <dev@apr.apache.org>
Subject: RE: [PATCH] speed up network timeout processing
Date: Wed, 3 Jul 2002 11:33:13 -0400
Message-ID: <JHEPKCEMGPKFFDHHDDKDAEKAEKAA.bill@wstoddard.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-reply-to: <00c301c222a5$efd1fda0$5000000a@KOJ>
Importance: Normal


> > From: Bill Stoddard [mailto:bill@wstoddard.com]
> >
> >
> > > > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > > >
> > > > A little bird told me that FD_ZERO() burns lots of cycles in
> > > > apr_wait_for_io_or_timeout().  It turns out that this is an easy
> > > > conversion to poll(), which doesn't have such overhead in the
> > > > interface.
> > > >
> > > > This works for me with some testing (timeouts on read and write
> work
> > > > for me).
> > >
> > > Can we remove the #ifdef's by just using apr_poll here?
> > >
> > > Ryan
> >
> > I'd prefer not to do that. calling apr_poll will just add extra
> function
> > call overhead. This code is pretty simple (ie, the #ifdef does not
> > signicantly impact code readability).
>
> This is bogus.  If apr_poll is so heavy-weight that APR can't use it,
> then it is just too heavy-weight.  Avoiding the function doesn't do
> anything other than prove that apr_poll is not useful in its current
> form.  FIX THE PROBLEM!

What problem?  I have NO problem with the code as it is. I see NO advantage
to using apr_poll() in this particular application. apr_wait_for_timeout()
takes two arguments, an apr_socket and a flag indicating whether the poll is
for a read or a write. There are no opportunities to set the pollset in this
function so why in the world do you want to add all the extra function calls
to use apr functions to set the pollset? That's just goofy Ryan.

Bill