Frank Cusack wrote:
On May 4, 2007 4:28:06 AM +0200 Alan DeKok <aland@deployingradius.com>
Suggestions?
Add a config_t * to a REQUEST. This would be exactly how you would do it with some other library that is handling configuration. (Except with some other library the config_t * probably has both data and methods.)
The config_t itself would have a refcount (this can be updated via atomic ops which don't require a mutex). Then on HUP (or some type of reconfig message), a new thread runs which reads the new config and globally marks it current. New REQUESTs get assigned the new config. The config thread waits for the refcount on the old config to go to 0, then reclaims the memory and then exits.
Also, re-instantiate all modules. The new instance will pick up the new config. When all previously running threads finally complete, destroy the previous module instances.
I assume the problem then comes in the handling of further packets for preexisting state, such as proxy replies and eap? I suppose in that case, abandoning those wouldnt be so terrible, especialy as compared to a full restart which what most admins/distributions in the real world who havent implemented EVERYTHING via sql will be/already are doing.