apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [design] work around new apr_poll leakage?
Date Mon, 22 Jul 2002 04:17:26 GMT
Congratulations.  You have just designed the interface that was removed
two weeks ago.   :-(

BTW, that interface was removed because it was too bulky and complex and
too slow.


Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Brian Pane [mailto:brianp@apache.org]
> Sent: Thursday, July 18, 2002 11:28 PM
> To: dev@apr.apache.org
> Subject: Re: [design] work around new apr_poll leakage?
> William A. Rowe, Jr. wrote:
> > At 11:21 PM 7/18/2002, Brian Pane wrote:
> >
> >> I'm almost in complete agreement with this proposal.  We
> >> need a wrapper object to hold the temp pollset so that we
> >> can re-use it for all subsequent poll calls on the same
> >> fd set.
> >
> >
> > Notice that apr_pollfd_internal_t *int; below _IS_ entirely
> > opaque...  [and using a reserved keyword, the member name
> > REALLY sucked... how about simply *private.]
> Right, but the pointer to the vector of apr_pollfd_t
> objects is transparent.  And that's the one that will
> cause problems if we try to use something like /dev/poll,
> because the set of descriptors in that vector can get
> out of synch with the descriptors that have been registered
> with /dev/poll.
> (Yes, we could avoid that problem by including within
> the apr_pollfd_internal_t a list of the descriptors that
> we used on the last poll call for this apr_pollfd_set_t,
> which would make it possible to detect added/removed
> descriptors since the last call.  But that would require
> an O(n)-time scan through the entire vector on each request,
> which defeats the scalability advantages of using a
> faster poll interface.)
> Speaking of linear-time code, I just checked the current
> apr_poll(), and it's doing an O(n)-time loop to copy from
> the apr_pollfd_t structs to the pollfd structs.  That's
> a major scalability problem for larger values of n.
> Fortunately, your new design offers a way to fix the O(n)
> problem: build the pollfd vector once, and re-use it on
> subsequent calls if the apr_pollfd_t vector hasn't changed.
> (The transparency of the apr_pollfd_t vector and apr_pollfd_set_t
> makes this a little tricky, though.)
> --Brian

View raw message