We're building a RADIUS server that will act as the front end to another authentication system (a fancy way of saying we're implementing EAP-SIM). Our system requirements and tight schedule lead us to keep the design very simple yet re-use as much existing code as possible. With that, I have two questions about the Freeradius threading mechansim. We have freeradius 0.8.1 running on Red Hat 7.2.
1. This may be an easy one but it may be relevant to the next one, so I'll ask to be sure. For now, we only want one thread to service all client requests. Should I run configure with "--with-threads=no", or should I leave threads in the build and change the thread pool settings in radiusd.conf to use start_servers = 1, max_servers = 1, and min and max_spare_servers = 0?
2. We have a framework that's derived from ACE that we use for our inter-subsystem communication. We would like to use this mechanism for freeradius communication with the backend. We believe we can define some extern "C" accessor functions for freeradius, and leave the C++ under the hood. Here's the question: This interface defines its own threads for managing the data flow through the socket. These are posix threads and use the same lpthread library that freeradius does. If we link this stuff into freeradius, will it clash somehow? Would using these other threads prevent me from setting "--with-threads=no" above? I assume anything I set in radiusd.conf only affects freeradius threads, not others that are also linked in.
In general, I guess I'm asking how to merge in new code that uses threads, while using only one thread for freeradius services.
Regards, Dave
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
