On May 4, 2007 4:28:06 AM +0200 Alan DeKok <aland@deployingradius.com> wrote:
Frank Cusack wrote:
Yes. The problem is simplified by having almost everything tied to a REQUEST. So anything "live" is either a thread handling a REQUEST, or a REQUEST waiting for something. And REQUESTs point to clients & home servers via one pointer, which is easy to manage.
Easily done without SQL.
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.
After spending some time on this, there isn't a ready-made solution that I've found. Looking on the net, few servers other than OpenLDAP support dynamic run-time changes to the config. And they all do so via a DB interface.
BIND named has reconfig and doesn't use a DB interface. -frank