rlm_perl behavior

[Borislav Dimitrov]

>
> I hope this implementation will satisfy Borislav too. Will he be  
> able to
> instantiate different perl scripts for different needs?
>
> So, when do I start testing :)

Hi,

Yes, being able to instantiate and use several rlm_perl instances with  
different scripts to take care of different circumstances is what will  
make me and many others (I think) happy.
Sacrificing the *_clones flexibility for lower memory footprint,  
better performance and more importantly code is certainly worth doing  
it, if people are still able to have multiple rlm_perl instances. I  
imagine that probably the best way will be to have X (the number of  
rlm_perl instances) per system thread - this is the way it'd be if  
they were different modules (like sql, preprocess etc) which custom  
Perl scripts executing under rlm_perl a kind of are...
For now I downgraded to 2.0.5 which works perfect for me but will be  
happy to help with testing (on some client's production system...  
don't tell anyone ;-) ).

OFFTOPIC:
Btw, do you know of some existing effort to develop rlm_ruby? What's  
its state etc? I had the ambition to develop something like that  
myself but don't have the time anymore :-(.

On 16.04.2009, at 20:17, Apostolos Pantsiopoulos wrote:

> Alan DeKok wrote:
>> Boian Jordanov wrote:
>>> From my point of view we should have  pool of perl clones per each
>>> module instance.
>>  Yes.
>>> This way we could have multiple perl instances (each with its own  
>>> perl
>>> script to run).
>>  Yes.
>>> Limiting on perl clone or interp per server thread will limit the
>>> multiple instances feature of rlm_perl.
>>  We don't need that limit.  The server should not be running more  
>> Perl
>> threads than system threads.  It also should not be running less Perl
>> threads than system threads.
>
> My point exactly.
>
>>  It should be running one Perl thread per system thread.  The server
>> core already manages min/max spare threads, idle threads, etc.
>
> I totally agree. In the old config I used to have the same clone= and
> max_servers= directives to achieve that.
>
>>> Again playing with min and max spare can give us some  
>>> possibility's  to
>>> force not unload perl interpreter during the lifetime of server  
>>> and this
>>> way we can keep some DB handlers not to reconnect each time.
>>>
>>> Alan what is your point ?
>>  The pthread keys in the current rlm_perl should be moved to the
>> "perl_inst" struct.  The keys should be allocated per thread, and not
>> via pthread_once.
>
> I hope this implementation will satisfy Borislav too. Will he be  
> able to
> instantiate different perl scripts for different needs?
>
> So, when do I start testing :)
>
>>  Alan DeKok.
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>
> -- 
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html