On Tue, May 4, 2010 at 4:00 PM, Jeff Trawick <[email protected]> wrote: > On Tue, May 4, 2010 at 3:16 PM, William A. Rowe Jr. <[email protected]> > wrote: >> Here's a backport vote to 2.2 for your consideration; >> >> It is far too painful to adopt the new Mutex directive for modules targeting >> httpd 2.2 and future 2.3. > > From your example URL below, it looks like a developer can maintain > only about 15-20 extra LOC in order to utilize the new Mutex feature > of 2.4 and at the same time continue working exactly the same for the > other httpd versions. > > Wouldn't they rather do that than deal with migration as users move to > a later httpd 2.2 and then, perhaps much later, rebuild the > third-party module? ("do you have a LoadModule for mod_mutex?"; > "FooLogMutex isn't supported once you rebuild with httpd 2.2.19"; > "please download mod_mutex from svn and build with apxs", depending on > the choice of the module author) > >> The solution, I believe, is to provide the mutex >> directive for all developers to use, and simply not adopt it within httpd >> itself >> until our jump to 2.4 happens.
If mod_mutex gets added to 2.2, I'd suggest a nuance to this "not adopt" stance: If the httpd-bundled module currently has no mutex configuration and it is necessary to solve some operational problem, go ahead and use the mod_mutex feature. But for mod_ssl and others that already provide configuration, leave it as-is. >> >> To that end, I've hacked together >> http://people.apache.org/wrowe/mod_mutex.c >> http://people.apache.org/wrowe/util_mutex.h >> which I'm propose we adopt for inclusion in both our httpd 2.2 and 2.0 trees >> under >> 'experimental/', and default to build 'most' (effectively, an ever present >> no-op, >> until they add an external module that relies on it). > > trivial: I don't think "experimental" and "most" are consistent. > >> If this is accepted, it would become a prereq for users adopting new releases >> of mod_fcgid or mod_ftp. > > separate issue/vote (maintain those extra LOC in mod_fcgid until it is > folded into trunk for 2.4* vs. require migration step for users of > older httpd) > > *yet another issue :) > >> You can review the source code to see how badly we >> need a simpler solution; >> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_mutex_unix.c?view=markup&pathrev=885868 >> - of course the user of a slightly >> older 2.2.x or 2.0.x could simply build mod_mutex with apxs and then their >> module, >> and they also must install util_mutex.h for dependent module builds to >> succeed. >> >> So please review and opine... >> >> +/-1 > > [+0.5 concept] Adopt mod_mutex.c on httpd 2.2.x svn branch > > I haven't looked at mod_mutex, but no big concerns here; the API is > useful; I'd guess some module authors would be relieved to use that > feature if their users currently have mutex issues that require > configuration, and the module doesn't already provide that > > [-0.8] Adopt mod_mutex.c on httpd 2.0.x svn branch > > - too late for new features unless absolutely critical to solve some > operational problem > - not abundantly clear that there will ever be 2.0.next, so developers > shouldn't think that mod_mutex solves their issue for support of that > server, unless of course the developer wants to hand-hold the download > and build of mod_mutex > > -- Hmmm, at least one e-mail client thinks the remaining text is a sig because of my poor choice of separator. > Wild guess: maybe mod_mutex for 2.0/2.2 just needs a home somewhere in > httpd-land, outside of the main server distribution? I have a couple > I'd put in the same LIFEboat. > -- Born in Roswell... married an alien...
