httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Solving util_mutex pain?
Date Thu, 20 May 2010 23:33:06 GMT
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.

> 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.




Mime
View raw message