You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2004/09/17 21:19:14 UTC

[Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

I noticed browsing some code that there is a threaded_mpm field in mp's 
server config structure.

That is a global proprety and doesn't have to live in the server config, 
so this patches replaces
that code with the (already there, but not used) threaded_mpm global.

It doesn't make a significant speed/memory improvement, but it removes a 
bit of unnecessary
logic.



Re: [Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:

> Philippe M. Chiasson wrote:
>
>> Stas Bekman wrote:
>>
>>> Philippe M. Chiasson wrote:
>>>
>>>> Stas Bekman wrote:
>>>>
>>>>> Philippe M. Chiasson wrote:
>>>>>
>>>>>> I noticed browsing some code that there is a threaded_mpm field 
>>>>>> in mp's server config structure.
>>>>>>
>>>>>> That is a global proprety and doesn't have to live in the server 
>>>>>> config, so this patches replaces
>>>>>> that code with the (already there, but not used) threaded_mpm 
>>>>>> global.
>>>>>>
>>>>>> It doesn't make a significant speed/memory improvement, but it 
>>>>>> removes a bit of unnecessary
>>>>>> logic.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I wonder why do we need the modperl_global_ interface for that. 
>>>>> Won't a static variable do the trick?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Well, correct me if I am wrong, but I just thought the 
>>>> modperl_global_ interface was there mainly to clearly
>>>> identify globals and centralize their managments.  So that's why I 
>>>> thought it should be used.
>>>>
>>>> I guess the more important question is : What is the 
>>>> modperl_global_ interface intended for ?
>>>
>>>
>>>
>>>
>>> it's intended for manipulating globals while running workers, e.g.:
>>>
>>> lock_mutex
>>> set_global_foo
>>> unlock_mutex
>>>
>>> in another thread:
>>>
>>> lock_mutex
>>> get_global_foo
>>> unlock_mutex
>>
>>
>>
>> Yes, that's correct. (locking/unlocking isn't necessary since 
>> get_global_foo takes care of it)
>
>
> is does? I don't think so. It provides the API to do so, but doesn't 
> do that on get_/set_.

Yes, I don't know what I was looking at. It only provides the API for it.

In any case, I've made the change to a plain old global and checked it in.


Re: [Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
> 
>> Philippe M. Chiasson wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> Philippe M. Chiasson wrote:
>>>>
>>>>> I noticed browsing some code that there is a threaded_mpm field in 
>>>>> mp's server config structure.
>>>>>
>>>>> That is a global proprety and doesn't have to live in the server 
>>>>> config, so this patches replaces
>>>>> that code with the (already there, but not used) threaded_mpm global.
>>>>>
>>>>> It doesn't make a significant speed/memory improvement, but it 
>>>>> removes a bit of unnecessary
>>>>> logic.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I wonder why do we need the modperl_global_ interface for that. 
>>>> Won't a static variable do the trick?
>>>
>>>
>>>
>>>
>>> Well, correct me if I am wrong, but I just thought the 
>>> modperl_global_ interface was there mainly to clearly
>>> identify globals and centralize their managments.  So that's why I 
>>> thought it should be used.
>>>
>>> I guess the more important question is : What is the modperl_global_ 
>>> interface intended for ?
>>
>>
>>
>> it's intended for manipulating globals while running workers, e.g.:
>>
>> lock_mutex
>> set_global_foo
>> unlock_mutex
>>
>> in another thread:
>>
>> lock_mutex
>> get_global_foo
>> unlock_mutex
> 
> 
> Yes, that's correct. (locking/unlocking isn't necessary since 
> get_global_foo takes care of it)

is does? I don't think so. It provides the API to do so, but doesn't do 
that on get_/set_.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:

> Philippe M. Chiasson wrote:
>
>> Stas Bekman wrote:
>>
>>> Philippe M. Chiasson wrote:
>>>
>>>> I noticed browsing some code that there is a threaded_mpm field in 
>>>> mp's server config structure.
>>>>
>>>> That is a global proprety and doesn't have to live in the server 
>>>> config, so this patches replaces
>>>> that code with the (already there, but not used) threaded_mpm global.
>>>>
>>>> It doesn't make a significant speed/memory improvement, but it 
>>>> removes a bit of unnecessary
>>>> logic.
>>>
>>>
>>>
>>>
>>> I wonder why do we need the modperl_global_ interface for that. 
>>> Won't a static variable do the trick?
>>
>>
>>
>> Well, correct me if I am wrong, but I just thought the 
>> modperl_global_ interface was there mainly to clearly
>> identify globals and centralize their managments.  So that's why I 
>> thought it should be used.
>>
>> I guess the more important question is : What is the modperl_global_ 
>> interface intended for ?
>
>
> it's intended for manipulating globals while running workers, e.g.:
>
> lock_mutex
> set_global_foo
> unlock_mutex
>
> in another thread:
>
> lock_mutex
> get_global_foo
> unlock_mutex

Yes, that's correct. (locking/unlocking isn't necessary since 
get_global_foo takes care of it)

> in the case of threaded_mpm it's a set-once before threads/workers 
> appear, and then it's always read-only, so there are no thread-safety 
> issues, so i can't see what's the added value in using the 
> modperl_global_ interface for this.

You are right on this point. I wrongly assumed we were using the 
modperl_global_ infrastructure for all globals.
I'll change my patch and resubmit.

>
>


Re: [Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
> 
>> Philippe M. Chiasson wrote:
>>
>>> I noticed browsing some code that there is a threaded_mpm field in 
>>> mp's server config structure.
>>>
>>> That is a global proprety and doesn't have to live in the server 
>>> config, so this patches replaces
>>> that code with the (already there, but not used) threaded_mpm global.
>>>
>>> It doesn't make a significant speed/memory improvement, but it 
>>> removes a bit of unnecessary
>>> logic.
>>
>>
>>
>> I wonder why do we need the modperl_global_ interface for that. Won't 
>> a static variable do the trick?
> 
> 
> Well, correct me if I am wrong, but I just thought the modperl_global_ 
> interface was there mainly to clearly
> identify globals and centralize their managments.  So that's why I 
> thought it should be used.
> 
> I guess the more important question is : What is the modperl_global_ 
> interface intended for ?

it's intended for manipulating globals while running workers, e.g.:

lock_mutex
set_global_foo
unlock_mutex

in another thread:

lock_mutex
get_global_foo
unlock_mutex

in the case of threaded_mpm it's a set-once before threads/workers appear, 
and then it's always read-only, so there are no thread-safety issues, so i 
can't see what's the added value in using the modperl_global_ interface 
for this.



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:

> Philippe M. Chiasson wrote:
>
>> I noticed browsing some code that there is a threaded_mpm field in 
>> mp's server config structure.
>>
>> That is a global proprety and doesn't have to live in the server 
>> config, so this patches replaces
>> that code with the (already there, but not used) threaded_mpm global.
>>
>> It doesn't make a significant speed/memory improvement, but it 
>> removes a bit of unnecessary
>> logic.
>
>
> I wonder why do we need the modperl_global_ interface for that. Won't 
> a static variable do the trick?

Well, correct me if I am wrong, but I just thought the modperl_global_ 
interface was there mainly to clearly
identify globals and centralize their managments.  So that's why I 
thought it should be used.

I guess the more important question is : What is the modperl_global_ 
interface intended for ?

Re: [Patch mp2] [cleanup] Get rid of scfg->threaded_mpm

Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> I noticed browsing some code that there is a threaded_mpm field in mp's 
> server config structure.
> 
> That is a global proprety and doesn't have to live in the server config, 
> so this patches replaces
> that code with the (already there, but not used) threaded_mpm global.
> 
> It doesn't make a significant speed/memory improvement, but it removes a 
> bit of unnecessary
> logic.

I wonder why do we need the modperl_global_ interface for that. Won't a 
static variable do the trick?

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org