apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: [Request for comments] new poll API
Date Mon, 29 Jul 2002 16:46:11 GMT
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



Mime
View raw message