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
