Re: rlm_perl and threads
The old wiki used to contain more information on this. I'm currently in the process of making our rlm_perl module multithreaded as well. Some pointers: perl -V | grep -i multipl ... useithreads=define, usemultiplicity=define Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS check your multiplicity here. Multiplicity causes one perl process to be started, with multiple perl interpreters inside. Add a CLONE function to your perl script (yes, all in caps). The CLONE function is run every time a new perl interpreter is started. What happens is all existing variables are copied to the new interpreter when a new thread is started. In this function you can adjust values that should be unique for each thread (like database handlers). The number of threads are controlled trough the max_servers and max/min spare servers in your radiusd.conf Threading is not done in debug mode (-X), start your freeradius in normal mode to test multithreading. AFAIK the above information is correct and recent. Kind regards Sander Eerdekens Informatiesystemen Systeembeheer & Ondersteuning sander@uzleuven.be UZ Leuven | campus Gasthuisberg | Herestraat 49 | B - 3000 Leuven | www.uzleuven.be ------------------------------ Message: 5 Date: Mon, 05 Nov 2012 14:01:56 +0000 From: Phil Mayers <p.mayers@imperial.ac.uk> To: freeradius-users@lists.freeradius.org Subject: Re: rlm_perl and threads Message-ID: <5097C6D4.9070904@imperial.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 05/11/12 13:36, Edgar Fu? wrote:
Yes. Likely, even. Thanks. So will these then be two distinct Perl interpreters or two instances of the same Perl interpreter? From the Perl script's point of view, what will the two instances share? Can you hint me to any documentation covering this?
I'm not aware of any docs. You might need to refer to the source. In particular, the USE_ITHREADS #define seems to control how the perl interpreter is created/allocated/used. I'm not familiar enough with perl to understand the code, personally. See here: https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... ...and the rest of that file.
Thanks, this has been very helpful. If I read the source correctly, it works as follows: -- A "global" interpreter is created that runs the module initialization code. -- When a perl function is going to be called, the global interpreter is used in the non-threading case. In the threading case, if necessary, a thread-local interpreter is created by cloning the global one. So, in the non-threading case, I would have to perform initialization tasks like opening a database connection in the module init code. In the threading case, I have do to that in CLONE(). In the module init code, can I tell whether I'm in the threading case or not? It's probaby no harm besides a waste of resources to also do the full init there in the threading case, but I would like to avoid that if easily possible.
Threading is not done in debug mode (-X), start your freeradius in normal mode to test multithreading. I think this should be documented since one is always urged to test in debug mode.
Digging through the rlm_perl source, I stumbled over the following: 1. Is it on purpose that it normally checks USE_ITHREADS and only perl_xlat checks WITH_ITHREADS? 2. Is it also on purpose that radiusd::radog is newXS'd only after perl_parse()? That hit me because as it is, you can't log anything (like a version number) inside the script's body/main program (or call it initialization routine). 3. I also noticed that tests like #if PERL_REVISION >= 5 && PERL_VERSION <8 would trigger for 6.0 if that is ever going to happen.
Edgar Fuß wrote:
Digging through the rlm_perl source, I stumbled over the following:
1. Is it on purpose that it normally checks USE_ITHREADS and only perl_xlat checks WITH_ITHREADS?
No. It should be fixed.
2. Is it also on purpose that radiusd::radog is newXS'd only after perl_parse()?
No idea.
That hit me because as it is, you can't log anything (like a version number) inside the script's body/main program (or call it initialization routine).
Well, patches are welcome.
3. I also noticed that tests like #if PERL_REVISION >= 5 && PERL_VERSION <8 would trigger for 6.0 if that is ever going to happen.
Sure. Send a patch. Alan DeKok.
EF> Is it also on purpose that radiusd::radog is newXS'd only after perl_parse()? AdK> No idea. I'm not familiar with the FreeRADIUS project: Is there something like a maintainer of the rlm_perl module I could ask this question? AdK> Well, patches are welcome. That would be trivial: move the newXS() before the perl_parse(). But I'm not familiar enough with embeded Perl to know whether that would be legal (I could check whether it works in my environment, but if it does, that wouldn't mean anything). I guess there are people in the project much more competent than me on this subject.
Edgar Fuß wrote:
EF> Is it also on purpose that radiusd::radog is newXS'd only after perl_parse()? AdK> No idea. I'm not familiar with the FreeRADIUS project: Is there something like a maintainer of the rlm_perl module I could ask this question?
On this list. Alan DeKok.
participants (3)
-
Alan DeKok -
Edgar Fuß -
Sander Eerdekens