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: r...@kinetix.gr
-------------------------------------------
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
