Dave Mason <[EMAIL PROTECTED]> wrote: > 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.
I'm not sure why it would matter. > 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? Both will work. > 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? It shouldn't. If the software is written correctly, all of the thread management is done based on a data structure, and not on a 'master' thread. So long as the library is initialized, handled, and deleted, all based on that data structure, having multiple threads shouldn't cause much of a problem. > Would using these other threads prevent me from setting > "--with-threads=no" above? No, but you might have to play with the make files. > In general, I guess I'm asking how to merge in new code that uses > threads, while using only one thread for freeradius services. I'm not sure why having one thread for FreeRADIUS would be a requirement. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
