On Wed, Mar 25, 2009 at 8:53 PM, Nick Kew <[email protected]> wrote:
>
> On 24 Mar 2009, at 21:45, Jeff Trawick wrote:
>
> something I'm in a relative hurry to get feedback on is this part:
>>
>> 2. retain data
>>
>> How can MPMs retain data across unload of the DSO?
>> s->process->server_pool userdata
>> won't work as-is because there's no server_rec in the pre_config hook.
>>
>
> Is there a need for an API here? As opposed to the MPM working with
> its own file-scope static variables, for instance?
>
File-scope static variables don't work for DSOs (for data retained across
unload/reload) since the variables are re-instantiated at reload.
That led to the following idiom in quite a few modules:
const char *userdata_key = "rewrite_init_module";
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (!data) {
first_time = 1;
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
}
(This is a simple use with just a flag.)
That's more gory than it needs to be, and MPMs needed this capability in the
pre-config hook, when there is no s->process->pool; hence the need for a
change.
>
>
>> Proposal: Add ap_set_retained_data(key, value),
>> ap_get_retained_data(key) APIs
>> (implementation detail: it will set/get userdata on pglobal)
>>
>> Although not necessary, provide ap_get_config_count()
>> (better name!) to
>> indicate how many passes of config have completed. (The
>> interface could be
>> a global variable, but some third-party module would
>> inevitably clear it.)
>>
>
> Looks fine, if there is indeed a need for it.
Cool... Note that the final (working) interface is a bit different, where
ap_set_retained_data takes key + length, allocates the space, and returns
the address to the caller.
