Ryan Bloom wrote:
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.
Sorry, but I don't think so. The facts are simple. You said that
apr_poll was both too slow and too complex for use inside of APR.
Jeff said it was too slow and complex for a specific use case
inside APR. You generalized that to "apr_poll is too slow for
APR to use," but the generalization isn't valid. There are
many cases inside APR where the implementation uses an inline
variant of some other APR API for performance reasons (the
array and string APIs are two examples that come to mind
immediately). Such cases don't mean that the API being bypassed
is unsuitable for use as a public API. They simply mean that
the code that's bypassing them has used an appropriate
optimization to deliver high performance to its own callers.
--Brian
