You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2010/05/04 21:16:26 UTC
Solving util_mutex pain?
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
Re: Solving util_mutex pain?
Posted by Eric Covener <co...@gmail.com>.
On Tue, May 4, 2010 at 5:51 PM, Nick Kew <ni...@webthing.com> wrote:
>
> On 4 May 2010, at 20:16, William A. Rowe Jr. wrote:
>
>> To that end, I've hacked together
>> http://people.apache.org/wrowe/mod_mutex.c
>> http://people.apache.org/wrowe/util_mutex.h
>
> I'm getting 404 on both those URLs. What gives?
missing ~
--
Eric Covener
covener@gmail.com
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/4/2010 4:51 PM, Nick Kew wrote:
>
> On 4 May 2010, at 20:16, William A. Rowe Jr. wrote:
>
>> To that end, I've hacked together
>> http://people.apache.org/wrowe/mod_mutex.c
>> http://people.apache.org/wrowe/util_mutex.h
>
> I'm getting 404 on both those URLs. What gives?
Missed a tilde, sorry (!)
http://people.apache.org/~wrowe/mod_mutex.c
http://people.apache.org/~wrowe/util_mutex.h
mod_mutex is 2.2 specific, although it wouldn't be hard to hack the 2.0 mpm
includes compatibility (that changed drastically between 2.2 and 2.0, and is
needed for the mutex set perms logic).
Re: Solving util_mutex pain?
Posted by Nick Kew <ni...@webthing.com>.
On 4 May 2010, at 20:16, William A. Rowe Jr. wrote:
> To that end, I've hacked together
> http://people.apache.org/wrowe/mod_mutex.c
> http://people.apache.org/wrowe/util_mutex.h
I'm getting 404 on both those URLs. What gives?
--
Nick Kew
Re: Solving util_mutex pain?
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1 from me.... tests good (thx for the reminder ping!)
On May 10, 2010, at 4:35 PM, William A. Rowe Jr. 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? FWIW there is a new rev .1 of the .h file that changes the
> unused data members into unused static functions. All my compilers apparently
> have no problems with the later.
>
> http://people.apache.org/~wrowe/util_mutex.h.1
>
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.
My concern is promoting the httpd 2.3 API to module authors. They are concerned
that 2.2 users are their audience, plus perhaps 2.0 users, and 2.4 users in the
not-too-distant future.
This makes porting to new 2.4 features less attractive. mod_mutex seeks to
minimize this downside for module developers. Doing so for
If your interest is allowing 'Mutex' control of existing 2.2 core mutexes, may
I suggest we still deal with the external use of the 'Mutex' directive as a
module component, since the alternative is that 2.2.16 users could take
advantage of it, but it would conflict with 2.2.15 users installing this
support as a component.
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/21/2010 8:13 AM, Jeff Trawick wrote:
>
> Somebody else say something either way :)
+1 :)
Re: Solving util_mutex pain?
Posted by Jeff Trawick <tr...@gmail.com>.
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.
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.
Re: Solving util_mutex pain?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, May 10, 2010 at 4:35 PM, William A. Rowe Jr.
<wr...@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)
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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? FWIW there is a new rev .1 of the .h file that changes the
unused data members into unused static functions. All my compilers apparently
have no problems with the later.
http://people.apache.org/~wrowe/util_mutex.h.1
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/4/2010 3:14 PM, Jeff Trawick wrote:
> On Tue, May 4, 2010 at 4:04 PM, Jeff Trawick <tr...@gmail.com> wrote:
>> On Tue, May 4, 2010 at 4:00 PM, Jeff Trawick <tr...@gmail.com> wrote:
>>> On Tue, May 4, 2010 at 3:16 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>>>> 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.
>
> suggestion withdrawn as it would be a required migration step for
> users of the module, even if they don't have a mutex configuration
> requirement (stepping away from the computer now)
Yea - I never intended this to replace any of 2.2's existing mutexes.
Now, if mod_wizbang is backported (becoming less and less likely to be accepted),
then it should be backported with a mod_mutex dependency, rather than developing
the dual code paths of 2.3 vs 2.2. Consistency is helpful, and they are going
to add the new directive to their 2.2 configuration whether it is WizbangMutex
or just Mutex. Since nobody ever added a WizbangMutex directive before, this
isn't a hardship.
I'll recommend that our next releases of mod_ftp and mod_fcgid rely on this
solution, be bumped by their version minor, and with the changes noted in the
readme. This simplifies both modules code, and the minor bump of the *module*
version level will signify to users that syntax/behavior is changing.
I suppose we could include mod_mutex itself in the mod_ftp/mod_fcgid packaging
to simplify things for the 2.2/2.0 user, if we wanted to.
I do expect to still tag at least one more 2.0 release, sometime in the near future,
and as we get towards 2.4 GA we would jettison 2.0 completely. Again, the ftp
and fcgid modules are good examples of why this module becomes useful, and the
code remains easier to maintain.
It also allows a user to adopt 2.3-beta modules in their existing 2.2 or 2.0
installations with much less hassle. The more early testing of 2.3 in the real
world, the better.
Re: Solving util_mutex pain?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, May 4, 2010 at 4:04 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, May 4, 2010 at 4:00 PM, Jeff Trawick <tr...@gmail.com> wrote:
>> On Tue, May 4, 2010 at 3:16 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>> 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.
suggestion withdrawn as it would be a required migration step for
users of the module, even if they don't have a mutex configuration
requirement (stepping away from the computer now)
Re: Solving util_mutex pain?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, May 4, 2010 at 4:00 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, May 4, 2010 at 3:16 PM, William A. Rowe Jr. <wr...@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...
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/5/2010 3:07 PM, William A. Rowe Jr. wrote:
> On 5/4/2010 3:00 PM, Jeff Trawick wrote:
>>
>> 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
>
> Or when their module code is dodgy, let's face it, until this API, things
> haven't been easy for handling mutexes.
>
> There is a disadvantage of this code, improvements welcome; you'll find
> a module using ap_global_mutex_create will emit;
>
> /usr/include/apache2/util_mutex.h:209: warning: 'ap_proc_mutex_create_ptr' defined but not
> used
>
> and visa versa for proc users. Ideas?
I flipped these from being module-static datum to creating light static wrapper
functions with internally static storage, and at least on gcc 4.2.1 it's quieted
down the warnings entirely. See the new alternative .h file;
http://people.apache.org/~wrowe/util_mutex.h.2
Re: Solving util_mutex pain?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/4/2010 3:00 PM, Jeff Trawick wrote:
>
> 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
Or when their module code is dodgy, let's face it, until this API, things
haven't been easy for handling mutexes.
There is a disadvantage of this code, improvements welcome; you'll find
a module using ap_global_mutex_create will emit;
/usr/include/apache2/util_mutex.h:209: warning: 'ap_proc_mutex_create_ptr' defined but not
used
and visa versa for proc users. Ideas?
Re: Solving util_mutex pain?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, May 4, 2010 at 3:16 PM, William A. Rowe Jr. <wr...@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.
>
> 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
--
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.