Justin Erenkrantz wrote:
On Fri, Jul 26, 2002 at 07:50:55PM -0700, Brian Pane wrote:
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. This is basically
the current implementation, but with a limit on the number
of descriptors that it will accept. With this limit, we
can put the temporary pollfd array on the stack in apr_poll()
to eliminate the memory leak.
My one concern is whether we can degrade gracefully if someone
calls with a too-high value to apr_poll(). Would it return an
error, or have the overhead of using the abstract API and then calling the other variant for you?
It would return an error in this case. My rationale is that creating and destroying a temporary instance of the abstract pollset object is likely to be expensive--multiple syscalls, for example, if it's implemented using /dev/poll. The abstract pollset is really best suited for applications that re-use the same pollset (potentially with descriptors added and removed incrementally) many times to amortize the cost of the creation/deletion over many poll calls.
If the app wants to call the "quick and dirty" form of the poll API with two hundred socket descriptors, IMHO that's a problem with the application design. And rather than trying to make it work, we should just let the application developer fix their code to use a persistent pollset object and the abstract API.
The reason is that if the limit of apr_poll() is tunable at
compile-time, then what may work for one installation may not
work for another. That worries me. I definitely don't want
to have to check for apr_poll() returning an error and then
having to code up for apr_pollset... -- justin
I think we can solve that one, though, by just declaring that the limit can never be changed. E.g., we can't decrease the limit (though we could potentially increase it) in future releases of APR, and applications can't re-#define it.
Brian
