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 18:17:17 GMT
Jeff Trawick wrote:

>Brian Pane <brianp@apache.org> writes:
>
>  
>
>>Jeff Trawick wrote:
>>
>>    
>>
>>>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?
>>>
>>>      
>>>
>>                                                              But the
>>main limitation of the general-purpose API is that, because it involves
>>some memory allocation, you can't use it for spontaneous, one-time poll
>>calls (like checking for readability on a single input socket if read
>>just returned EAGAIN) unless you can guarantee that the number of such
>>calls during the lifetime of the request pool has an upper limit.
>>    
>>
>
>This is the sort of thing I thought we'd start discussing a couple of
>hours ago :)
>
>The current implementation is useful if the user has to find out if
>the socket is readable/writable WITHOUT CONSUMING THE DATA and it is
>inconvenient to keep track of the APR representation of the
>pollset. If they are going to turn right around and consume the data
>then they might as well play with socket options and call apr_recv().
>If it is convenient to keep track of the APR representation of a
>pollset, then it doesn't matter either way.
>
>I'm not sure that I see the compelling use-case but for various
>reasons it is probably best for me to assume that there are plenty of
>them.  Hopefully having a separate API won't be confusing to APR
>programmers.
>
>ugh :)
>
>  
>

hmmm...another characteristic of the use case in which the current
API is useful is that there's exactly one descriptor involved.  Would
that yield a useful simplification of the two-API plan?  I'm thinking
of something like:

  - apr_pollset API for general-purpose use (abstract interface,
    does its own memory management, etc)

  - lightweight API that just checks a single descriptor for readability
    or writability

Of course, if we can only come up with a single use case for the second
API, and it happens to be apr_wait_for_io_or_timeout(), then let's just
inline the poll/select call there and forget about the lightweight API
until we find another use case.

--Brian



Mime
View raw message