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