HUP handling: a thought

[Joe Maimon]

Frank Cusack wrote:

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