httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject [PATCH/HEADS UP] mutex method configuration cleanup for 2.4
Date Sat, 21 Nov 2009 22:24:46 GMT
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?

Mime
View raw message