httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: svn commit: r912666 - in /httpd/httpd/trunk: CHANGES include/util_mutex.h server/core.c server/util_mutex.c
Date Thu, 25 Feb 2010 22:01:32 GMT
On 2/24/2010 6:44 AM, Jeff Trawick wrote:
> On Tue, Feb 23, 2010 at 11:07 PM, William A. Rowe Jr.
> <> wrote:
>> On 2/22/2010 11:16 AM, wrote:
>>> Author: trawick
>>> Date: Mon Feb 22 17:16:29 2010
>>> New Revision: 912666
>>> URL:
>>> 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 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.

View raw message