perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
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? */

     next = ++*(int *)(;


     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     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message