> From: Ryan Bloom [mailto:[EMAIL PROTECTED] > Sent: 09 July 2002 15:46
>> From: Ryan Bloom [mailto:[EMAIL PROTECTED] >>> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] >>> On Sat, Jul 06, 2002 at 12:11:59PM -0700, Ryan Bloom wrote: >>>> parameters. I would like to fix that mistake for apr_poll now, as >>>> long as we are changing the implementation. >>> >>> Getting back to this conversation for a brief second, I think the >>> additional parameter with the fd count is unneeded (but for a >>> different reason than IN/OUT). The count should be stored in >>> apr_pollfd_t - it does not need to be passed into apr_poll(). >> >> The count should absolutely NOT be stored in apr_pollfd_t. That is >> user owned structure, not an APR owned structure. > > I should clarify this. The whole point of this change, is that the user > can do the following: [...] > That code will work. Notice that no where before the apr_poll, did we > tell the poll implementation the size of the pollset. Nor can we. This > is where the real performance benefits of this patch come in. Because > the user has complete control over the pollset, we can remove all but > one pool allocation, and that one can be removed with an optimization > for small pollsets. > > Now, we can make macros to add sockets and files, but we should not EVER > be telling APR how many descriptors we are polling until we call > apr_poll(). The functions that currently setup the pollset and add > sockets and set events and revents are all deprecated, and were only > left in the patch to allow for as much source backwards compat as > possible while the patch is being discussed. Once the patch has been > committed, I will go through the source and start to remove those > functions completely. The only real example of apr_poll() that is a > part of the patch is wait_for_io_or_timeout. I probably didn't make > that clear enough. Ah, no. Without the accessor functions it doesn't make much sense to store the pollset size in apr_pollfd_t. I surely didn't see removing the accessor functions comming. Not sure if I like that (+0, -0). I can see the perf benefit, but if it makes for a better API, I don't know. Oh well, my $0.02, Sander
