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 Sat, 27 Jul 2002 19:49:37 GMT
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.


View raw message