current status of loadable MPM changes

[Jeff Trawick <tr...@gmail.com>]

http://people.apache.org/~trawick/loadable_mpms.txt

(you'll find additional stuff I forgot/didn't realize before long)

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.

   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.)

Re: current status of loadable MPM changes

[Jeff Trawick <tr...@gmail.com>]

On Wed, Mar 25, 2009 at 8:53 PM, Nick Kew <ni...@webthing.com> 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.

Re: current status of loadable MPM changes

[Nick Kew <ni...@webthing.com>]

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?

>
>    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.

-- 
Nick Kew