perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2 patch] anon subs B::Deparse deployment replacement
Date Wed, 24 Nov 2004 19:20:38 GMT
Sorry for taking so long to reply, I got back to work on this code now.

>>>> - i'm not sure if I can use a static global variable as a mutex (see
>>>>   XXX in the patch)
>>
>>
>>> I don't think there is a problem with that. But couldn't the 
>>> modperl_global.*
>>> stuff be used for this instead ?
>>
>>
>> I thought of that.
>>
>> 1) I'm not sure it's a good idea to use a single mutex for several 
>> unrelated tasks. That'll slow things down.
> 
> 
> As far as I can see, each different modperl_global entrie defined with
> the use of MP_GLOBAL_DECL() gets it's own mutex.

that's correct. I've failed to see that behind multiple macros :(

>> 2) I'm not sure how to get hold of that modperl_global variable when 
>> we need it.
> 
> 
> You don't need it. You can just :
> MP_GLOBAL_DECL(anonsub_cnt, int)
> 
> And you then get modperl_global_get_anonsub_cnt() for free.

I don't need it for free, since I need to increment and do locking anyway, 
so I did use the global type, but I've replaced the MP_GLOBAL_DECL with just:

/*** anon handlers code ***/

static modperl_global_t MP_global_anon_cnt;

void modperl_global_anon_cnt_init(apr_pool_t *p)
{
     int *data = (int *)apr_pcalloc(p, sizeof(int));
     *data = 0;
     modperl_global_init(&MP_global_anon_cnt, p, (void *)data, "anon_cnt");
}

int modperl_global_anon_cnt_next(void)
{
     int next;
     /* XXX: inline lock/unlock? */
     modperl_global_lock(&MP_global_anon_cnt);

     next = ++*(int *)(MP_global_anon_cnt.data);

     modperl_global_unlock(&MP_global_anon_cnt);

     return next;
}

since this is all is needed. What do you think about XXX? should I replace 
those calls with copy-n-pasted locking code? I see they aren't MP_INLINE 
so I'm not sure whether the compiler will inline those for us.

>> [...]
>> as for APR_ANYLOCK, why doug has used the perl locking routines in 
>> first place?
> 
> 
> Only reason I can see is that if you use Perl's locking routines, when they
> are not needed (i.e. no-ithreads), they are #defined as no-ops, while 
> apr_anylock
> stuff does have a small overhead even if you pick the apr_anylock_none 
> type (one
> pointer dereferencing + integer cmp).

so it's the best to stick with perl locking functions then.

Thanks Philippe!


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


Mime
View raw message