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 13:47:42 GMT
> >>new implementation results in an O(n) time wrapper (due to the need
to
> >>copy n pollfd objects on every poll call), not to mention the memory
> >>
> >>
> >leak.
> >
> >
> >>>BTW, that interface was removed because it was too bulky and
complex
> >>>
> >>>
> >and
> >
> >
> >>>too slow.
> >>>
> >>>
> >>>
> >>Please go ahead and revert the new implementation.  If we need to
tune
> >>
> >>
> >the
> >
> >
> >>old implementation, let's do that.
> >>
> >>
> >
> >No, the old design was completely bogus.  As proof, Trawick vetoed
even
> >using the damned thing inside of APR.  I don't care if you think that
we
> >don't have to use it, if a developer of APR believes that the API is
too
> >ugly to use in their code, then the API is borked.  Damn, I hated the
> >API and I designed it.
> >
> >The current API is correct, because it gives the user back control of
> >their memory.
> >
> 
> The current API has a memory leak that makes it unsuitable for
> general-purpose use (including the httpd).  That's why I vetoed it.

Thatis just BS.  This conversation started today with a solution to the
memory leak.

Ryan



Mime
View raw message