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:00:36 GMT
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.
>
> 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.

Mime
View raw message