Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

[PATCH/HEADS UP] mutex method configuration cleanup for 2.4

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


trawick at gmail

Nov 21, 2009, 2:24 PM

Post #1 of 2 (388 views)
Permalink
[PATCH/HEADS UP] mutex method configuration cleanup for 2.4

See http://people.apache.org/~trawick/mutex-directive-1.txt

This follows Joe's suggestion for one new Mutex directive utilizing
existing ap_parse_mutex(); it doesn't allow a list of mutexes on a
single Mutex directive though (feel free once I commit).

Key differences in the patch vs. current trunk:

a) modules now use httpd APIs to create global or proc mutexes if they
want to tie in to the Mutex config directive; an extra call is
required in the pre-config hook to register a type name for the mutex
and indicate whether or not the "none" no-op mechanism is supported
for that mutex; existing APR APIs are used once the mutex is created

b) there's no way to configure AcceptMutex lock file just in case
mutex is file-based; OTOH, adding a directive like this moves all
mutexes that use the new APIs:

Mutex default fcntl:/tmp/lockfiles

I guess we could allow something like

Mutex default if-file:/tmp/lockfiles

which would only change the default path, and not change the mechanism.

c) no more LockFile, AcceptMutex, WatchdogMutexPath, or RewriteLock;
the Mutex directive does it all; hopefully you need to code it in
fewer situations now as well

d) mod_rewrite always creates rewrite-map lock even if unnecessary
(currently it doesn't create it unless you tell it to, and it
complains if it was required); this can be optimized this later

e) more modules gain mutex configuration capabilities: mod_ldap,
mod_auth_digest, mod_watchdog (would only allow configuring the lock
file, not the mechanism); mod_example_ipc ;)

f) mod_watchdog now uses the default mechanism by default, instead of
either fcntl or flock if available; I didn't understand why it wanted
a file-based mutex, so I axed it ;)

Todo:

a) update mod_ssl as well, at the same time getting rid of the
requirement to explicitly configure an ssl cache mutex if you're going
to use a cache; likely I will leave it creating the cache mutex
whether needed or not, and let this aspect be optimized later (the
"extra" mutex won't generally be extra once mod_ssl is fixed to enable
a cache by default)

b) hide ap_parse_mutex(); the API wasn't in 2.2, I don't see why it
needs to be visible now that mutex configuration is handled
automatically for modules that use the new mutex creation API

c) see if the code can be cleaned up, test more, commit

d) post suggestions on how to change documentation, wait for feedback

Any concerns with the direction, or improvements to the current patch?


trawick at gmail

Nov 23, 2009, 9:06 AM

Post #2 of 2 (342 views)
Permalink
Re: [PATCH/HEADS UP] mutex method configuration cleanup for 2.4 [In reply to]

On Sat, Nov 21, 2009 at 5:24 PM, Jeff Trawick <trawick [at] gmail> wrote:
> a) update mod_ssl as well, at the same time getting rid of the
> requirement to explicitly configure an ssl cache mutex if you're going
> to use a cache; likely I will leave it creating the cache mutex
> whether needed or not, and let this aspect be optimized later (the
> "extra" mutex won't generally be extra once mod_ssl is fixed to enable
> a cache by default)

This wasn't correct, as mod_ssl only creates the ssl cache mutex if required.
(It is true that it requires you to explicitly configure an ssl cache
mutex when needed; I've removed that requirement in my patch.)

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.