apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [Request for comments] new poll API
Date Mon, 29 Jul 2002 15:27:50 GMT
"Ryan Bloom" <rbb@covalent.net> writes:

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

You are grasping for generalizations and taking a lot of liberties
with the facts along the way.

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

Are you suggesting that Apache is a use-case to support the simpler
flavor?  I'm not sure how.

I suspect that rebuilding the native pollset (e.g., struct pollfd
array) every time apr_poll() is called is harmful to Apache.

I suspect that rebuilding the abstract pollset (apr_pollfd_t array) in
its entirety after calling poll() is harmful to Apache, which is only
going to process the first match.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Mime
View raw message