On Wed, Oct 8, 2014 at 2:03 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > On Wed, Oct 8, 2014 at 1:50 AM, Lu, Yingqi <yingqi...@intel.com> wrote: >> 3. Yes, I did use some extern variables. I can change the name of them to >> better coordinate with the variable naming conversion. We should do >> something with ap_prefixed? Is there anything else I should consider when I >> rename the variable? > > Maybe defining new functions with more arguments (to be used by the > existing ones with NULL or default values) is a better alternative.
For example, ap_duplicate_listeners could be modified to provide mpm_listen and even do the computation of num_buckets and provide it (this is not an API change since it is trunk only for now). ap_close_listeners() could be then restored as before (work on ap_listeners only) and ap_close_duplicated_listeners(mpm_listen) be introduced and used in the MPMs instead. Hence ap_listen_rec *mpm_listeners could be MPM local, which would then call ap_duplicate_listeners(..., &mpm_listeners, &num_buckets) and ap_close_duplicated_listeners(mpm_listeners) That's just a quick thought... > > Please be aware that existing AP_DECLAREd functions API must not change > though. > > Regards, > Yann. > >> >> Thanks, >> Yingqi >> >> >> -----Original Message----- >> From: Yann Ylavic [mailto:ylavic....@gmail.com] >> Sent: Tuesday, October 07, 2014 4:19 PM >> To: httpd >> Subject: Listeners buckets and duplication w/ and w/o SO_REUSEPORT on trunk >> >> Hi, >> >> some notes about the current implementation of this (trunk only). >> >> First, whether or not SO_REUSEPORT is available, we do duplicate the >> listeners. >> This, I think, is not the intention of Yingqi Lu's original proposal, and >> probably my fault since I asked for the patch to be splitted in two for a >> better understanding (finally the SO_REUSEPORT patch only has been commited). >> The fact is that without SO_REUSEPORT, this serves nothing, and we'd better >> use one listener per bucket (as originally proposed), or a single bucket >> with no duplication (as before) if the performance gains do not worth it. >> WDYT? >> >> Also, there is no opt-in/out for this functionalities, nor a way to >> configure number of buckets ratio wrt number of CPUs (cores). >> For example, SO_REUSEPORT also exists on *BSD, but I doubt it would work as >> expected since IFAICT this not the same thing as in Linux (DragonFly's >> implementation seems to be closed to Linux' one though). >> Yet, the dynamic setsockopt() check will also succeed on BSD, and the >> functionality be enabled. >> So opt in (my preference) or out? >> >> Finally, some global variables (not even ap_ prefixed) are used to >> communicate between listen.c and the MPM. This helps not breaking the API, >> but this is trunk... >> I guess we can fix it, this is just a (self or anyone's) reminder :) >> >> Regards, >> Yann.
