rlm_perl behavior

[Boian Jordanov]

 From my point of view we should have  pool of perl clones per each  
module instance.
This way we could have multiple perl instances (each with its own perl  
script to run).
Limiting on perl clone or interp per server thread will limit the  
multiple instances feature of rlm_perl.
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 ?


Best Regards,
Boian Jordanov
SNE
Orbitel - Next Generation Telecom
tel. +359 2 4004 723
tel. +359 2 4004 002




On Apr 16, 2009, at 2:38 PM, Apostolos Pantsiopoulos wrote:

> Yes, that would be great. One perl interpreter
> per freeradius thread, that is. And I suppose the
> CLONE function would work again as expected (i.e. each
> freeradius thread would have its own perl interpreter and
> each script relaying on this interpreter would have its
> own connection to the DB). And the perl clones will not be
> controlled by the perl.conf (as in 2.0.x) but from the
> max_servers directive in  radiusd.conf, right?
>
> I am ready for testing whenever you have a patch ready.
>
> Alan DeKok wrote:
>> Apostolos Pantsiopoulos wrote:
>>> I understand that there may some benefits in the current
>>> implementation (2.1.x) such as less threads, smaller memory
>>> footprint etc. but why change something that has been tested
>>> and working in the first place?
>>  A quest to make it better.  If we were satisfied with the
>> functionality of the server in 1.0, we would have had no improvements
>> since then.
>>  In any case, it looks like it may be easy to change it so that there
>> is one Perl thread per server thread.  Would you be prepared to test
>> patches?
>>  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