On 2/24/2010 6:44 AM, Jeff Trawick wrote: > 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.
There can be within reason. I'm working on using the mutex API within the http://people.apache.org/~wrowe/mod_usage_track.c module in such a way that any change to the mutex setting will cause a new process-lifetime mutex to be used, and no change to the mutex setting will cause the same process-lifetime mutex to persist. So for scoreboard sorts of process lifetime resources, the unnamed mutex should survive server generations. Let me see if I can transition my work from mod_usage_track and mod_ssl before, and integrate these into the ap mutex creation API.
