On Tue, Feb 23, 2010 at 11:07 PM, William A. Rowe Jr. <[email protected]> wrote: > On 2/22/2010 11:16 AM, [email protected] wrote: >> Author: trawick >> Date: Mon Feb 22 17:16:29 2010 >> New Revision: 912666 >> >> URL: http://svn.apache.org/viewvc?rev=912666&view=rev >> Log: >> Fix startup segfault when the Mutex directive is used but no loaded >> modules use httpd mutexes. >> >> Add an init call from core's pre-config hook to ensure init is >> performed before the config is parsed. > > This logic seems broken. > > The problem is that anonymous mutexes against a persistant data store can't be > closed and reopened between server generations. This use of pre/post config > persists the broken design.
I guess "persist" means you believe the whole "Mutex" implementation doesn't allow persistent mutexes. See below for an attempt to split two different aspects -- "Mutex" directive vs. APR mutex. > This layer of init really should happen against process pool, within the scope > of the register hooks. No? > > There's no hassle for a named mutex object that corresponds to the persistent > object, e.g. a named file lock against a named database. Requirement 1: Modules can create mutexes that persist across restarts. Requirement 2: Configuration of mutexes can change across restart and, for example, removing a Mutex directive across restart would cause a mutex subsequently created of that type to use default settings. A mutex that persists across restarts will not pick up configuration changes, but there's no magic solution for that. Any data that manages the active Mutex configuration, which can change across restart, can be reinitialized in the pre-config hook, as long as it does not impact existing mutexes intended to be maintained across restart. (This particular commit is in this category.) The pool associated with any mutexes (not the configuration, just the mutex itself) should be chosen by the module based on the required lifetime. The mutex representation can't reference the data representing the active configuration. --/-- I think the current implementation meets these two requirements, though there's always room for implementation error. Do you have particular concerns I should check out?
