> Ryan Bloom wrote: > > >Congratulations. You have just designed the interface that was removed > >two weeks ago. :-( > > > > Exactly. The old API had the right design: an abstract poll object with > accessor functions, so that the poll wrapper can run in O(1) time. The > 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. 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. Ryan
