Dave Mason <[EMAIL PROTECTED]> wrote: > 1) I am adding a new EAP type to freeradius v0.8.1. It will need to > interact with a backend and wait for replies, so I would like each > authentication session to run in its own thread.
Why do you care? As I've said before, the whole point of the modules is that they don't know, or care about process/threading issues. > I notice in the module_t structure for RLM modules that the second > field, the type field, can be THREAD_SAFE or THREAD_UNSAFE. In > particular, rlm_eap has this set to THREAD_UNSAFE. Is this because > rlm_eap is indeed not thread safe, or is it because the implementors > simply chose not to use thread support with rlm_eap? I don't know. You'd have to look at the source code to be sure. > It seems risky to set this to THREAD_SAFE without knowing the whole > story. What should I do to add thread support? Nothing. Modules don't *do* threading. If you want to make the module thread-safe, then audit it, to be sure that every function it calls is thread-safe. If that's true, then set the THREAD_SAFE flag in the module data structure. > 2) It's possible I may have a requirement to have Accounting-Requests > conditionally proxy forwarded. That is, I could have an entry in > proxy.conf for the user's realm, and accthost set to some remote server. > Before forwarding the message, I would like to call some function which > would decide whether to forward the message as specified or drop it. That's what the pre_proxy section is for. > It's also possible I might need to generate an accounting record > locally, in addition to forwarding. In the same module_t structure, I > notice there is a pointer to a "pre-proxy" function. Can this be used > to do what I described? Yes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
