apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: [PATCH] speed up network timeout processing
Date Wed, 03 Jul 2002 15:33:13 GMT

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


Mime
View raw message