> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > "Ryan Bloom" <[EMAIL PROTECTED]> writes: > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > > Brian Pane <[EMAIL PROTECTED]> 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
