HUP handling: a thought

[Frank Cusack]

On May 4, 2007 4:28:06 AM +0200 Alan DeKok <aland at 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