httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
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.
> <wrowe@rowe-clan.net> wrote:
>> On 2/22/2010 11:16 AM, trawick@apache.org 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.


Mime
View raw message