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