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:45:42 GMT
> Ryan Bloom wrote:
> >Congratulations.  You have just designed the interface that was
> >two weeks ago.   :-(
> >
> Exactly.  The old API had the right design: an abstract poll object
> accessor functions, so that the poll wrapper can run in O(1) time.
> 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
> >BTW, that interface was removed because it was too bulky and complex
> >too slow.
> >
> Please go ahead and revert the new implementation.  If we need to tune
> 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.

You have a problem with looping through the pollset each time you call
apr_poll?  I have a problem with requiring 6 functions to manipulate the
pollset.  You can't do it with less than 6, we tried, and we always
ended up with 6.  Oh wait, 7 if you want both sockets and files.

You are optimizing for apps with large pollsets.  Fine, go ahead.
Create a wrapper structure with an opaque structure as Will suggested.
You want to re-use your pollset, figure out a solution.  But for apps
(like Apache, and most other non-async apps) with small pollsets, the
current implemented with a few tweaks is the correct implementation.


View raw message