apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [Request for comments] new poll API
Date Mon, 29 Jul 2002 18:58:07 GMT
At 01:17 PM 7/29/2002, Brian Pane wrote:

>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)

This is extremely effective for any poll-based server daemon.  We need
this so that the pollset can be manipulated for a group of listeners, and
it will become doubly necessary that it's very abstract if we will ever
support the async dispatch model in a poll-like fashion.

>  - 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.

>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.

I *really* empathize with Ryan that we should eat our own dogfood.  But
our dogfood is built for an application like the server's accept pollset, or
the several handles of a good cgi implementation.  We shouldn't convince
ourselves that the right solution for a one-of-many is the same solution
for a one-of-few, or a one-of-one.  And we shouldn't clobber the good of
the many for the good of the few, or the one :-)


View raw message