httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Solving util_mutex pain?
Date Mon, 17 May 2010 14:15:25 GMT
On Mon, May 10, 2010 at 4:35 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> On 5/4/2010 2:16 PM, William A. Rowe Jr. 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.  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.
>>
>> 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).
>>
>> If this is accepted, it would become a prereq for users adopting new releases
>> of mod_fcgid or mod_ftp.  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
>>   [  ]  Adopt mod_mutex.c on httpd 2.2.x svn branch
>>   [  ]  Adopt mod_mutex.c on httpd 2.0.x svn branch
>
> Any further votes?

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

2.0.x?  any way to get the one true mod_mutex is fine with me

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)

Mime
View raw message