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 21:51:01 GMT
William A. Rowe, Jr. wrote:

>>  - lightweight API that just checks a single descriptor for readability
>>    or writability
>
>
> We have that [this is what started the argument.]  But I'd argue that up
> to five or six sources are very useful, consider two ideas;
>
> 1. apr_poll learns to support brigades, so that a filter stack might be
>    plugged in later for cgi output.  This probably is a combination of 
> the
>    APR_SPECULATIVE interface [is there anything on the stack] and
>    a bit of intimate knowledge of the raw socket if there is nothing 
> useful
>    that's already sufficiently complete that is pending on the filter 
> stack.
>
> 2. cgi needs to poll the cgi's stdout / stderr and the client input 
> stack,
>    while polling the cgi's stdin and client response stack for 
> ready-to-write.
>
> This is a pretty tightly knit group of fd's that should be optimized 
> for the
> small-set case.


In both of these cases, though, I think the abstract API
would work just fine--and it might well be a better choice
than transparent API.  In both examples, the group of descriptors
would be long-lived (within the context of the request, at
least).  E.g., in the CGI case, we'd be doing a poll on the
same stdout/stderr repeatedly until we got the input.  And
the CGI handler is maintaining state between all those poll
calls, so it could easily use an instance of the general-purpose
abstract pollset object.  And if we use that pollset multiple
times in a typical CGI request, it's more efficient to use the
encapsulated API than the transparent one, because the
encapsulated one can amortize the O(n) cost of setting up the
internall pollfd array over multiple poll invocations.

The cases where we'd really need a multi-descriptor transparent
API are those where the application can't easily keep track of
a pollset object between calls.  I haven't been able to think of
a good example yet, though.

>> 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.
>
>
> Well, I've offered the bigger-than-one case, which will be true for many
> apps that poll on stdin/stdout and some other socket or file entity.  
> I really
> can't conceive of more than about 6 fd's in any obvious small-set case.
>
> But I agree, go with an abstract implementation, and make our existing
> apr_wait_for_io_or_timeout into the first special case.  It's so 
> darned simple
> that we shouldn't be trying to overwhelm it with multi-fd logic.


+1

Brian



Mime
View raw message