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 Tue, 04 May 2010 20:04:10 GMT
On Tue, May 4, 2010 at 4:00 PM, Jeff Trawick <trawick@gmail.com> wrote:
> On Tue, May 4, 2010 at 3:16 PM, William A. Rowe Jr. <wrowe@rowe-clan.net> 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...

Mime
View raw message