On Thu, May 20, 2010 at 7:33 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On 5/17/2010 9:15 AM, Jeff Trawick wrote: >> >> mod_mutex looks fine to me, but I'm not so happy that we're optimizing >> the situation for unbundled modules that want to use a new API with >> old 2.2.x, at the expense of existing bundled modules that may >> potentially require mutex configuration and should be able to do so >> using the streamlined API with zero migration impact. >> >> I'd prefer the combination of >> >> i. backport mutex API to 2.2.16 as part of core >> ii. "somehow" distribute mod_mutex.c + util_mutex.h for the very small >> set of users both >> a. stuck on old 2.2.x >> b. use certain, yet-to-be-determined unbundled modules with >> requirement for the new mutex API > > My thinking is that users of system-provisioned httpd may not have the luxury > of choosing 2.2.16, which is why I proposed a module instead of a backport.
I understand; I just don't think we should optimize for mod_ftp and unknown third-party modules at the expense of httpd-core-distro (by that I mean everything in httpd-2.2.x.tar.gz, some of which doesn't currently offer mutex cfg and could conceivably require it to solve user problems). That's my concern in a nutshell: It is optimized for (mostly) other people's stuff* and for users that stay on old releases, at the expense of "it just works" with httpd 2.2.16+. Delivering via mod_mutex is hardly a perfect solution for third-party modules, since they+ must tell (help) their users to download the latest httpd-2.2.x sources, grab mod_mutex, install it to their server with apxs, put util_mutex.h somewhere that the third-party module build will find it, and update httpd.conf to load mod_mutex too. *those modules/authors that don't want to maintain the extra 20LOC or so to work as-is with <= 2.2.15! or support mutex configuration with 2.2.16+ +well, this will bleed into the support aspect of our project as well !if critical for some module's user base they can still tell users to grab mod_mutex; the module just needs to use "#if HAVE_MOD_MUTEX || mmn-at-least()"; as you point out in your previous post, those mod_mutex users have a real migration impact when they upgrade to 2.2.16+: stop loading mod_mutex, and rebuild the third-party module so that it stops using the stubs that look for the optional function; definitely ugly; would be a showstopper if we think lots of users of existing httpd will be using non-core modules that force their user base to make the mutex API available Somebody else say something either way :) > >> 2.0.x? any way to get the one true mod_mutex is fine with me > > (ditto, and more significant - nobody chooses to be stuck at 2.0. External > forces like pointy-headed bosses must be at play :-) > >> A couple of unbundled modules have come up as part of this >> conversation... Here's what I'd suggest we do with mod_fcgid: >> >> 1. Use new mutex API if building with httpd >= 2.2.16. >> 2. Goto done; >> (AFAIK after n years of use there was one outstanding failure case >> caused by mutex defaults, and I fixed it programmatically; yes, >> "famous last words" and all that, but leave that sleeping dog alone >> until something has to be done) > > Speaking for mod_ftp as well, I'd like to eliminate this #if condition, > multiple > implementations case at the earliest convenience, accompanied by a minor rev > bump > to declare that 'Mutex' is now in use. The code begins to become as complex > as > httpd 1.3 main() in these corner cases, supporting several rev levels of > httpd :) > > Since most bugs are gone, users can stick w/ x.y.final, and if they want to > move > along with development and features, they can edit their Mutex config > statements > for new modules they plug in from 2.3 or third parties.
