apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [Request for comments] new poll API
Date Mon, 29 Jul 2002 14:59:01 GMT
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> "Ryan Bloom" <rbb@covalent.net> writes:
> 
> > > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > >
> > > Brian Pane <brianp@apache.org> writes:
> > >
> > > > To continue the recent discussions on the problems in the
current
> > > > apr_poll API, here's a patch for apr_poll.h that illustrates my
> > > > proposed fix.
> > > >
> > > > What I'm proposing here is to split the API into two parts:
> > > >
> > > >   - A lightweight, single-function poll API for use (only!)
> > > >     with very small sets of descriptors.
> > >
> > > Do we really need this API?  What is the sort of APR application
for
> > > which the heavy-duty API is harmful?
> >
> > I am biting my tongue here, but Jeff, you are the person who
> > specifically stated that the heavy-duty API was too slow for us to
use.
> 
> I said it was too slow and/or cumbersome to use in a particular
> situation that does not correspond to something an APR app would do,
> so I don't consider that a valid use-case for justifying the simpler
> API.  (An APR app should be using an APR timeout socket option for
> that situation.)

Let me see if I understand.  Apr_poll() is too slow for APR to use, but
because you don't expect APR apps to use it too often, that is okay.
Sorry, that doesn't hold water.

> Like I said above, I'd first like to see a description of an APR app
> that is harmed by doing the setup and using the accessor functions.
> This should be helpful in determining how important it is to support
> the simpler API flavor.

Well, Greg Ames used to say all the time that apr_poll was seriously
hurting the performance of Apache.

Ryan



Mime
View raw message