On May 4, 2007 1:40:16 PM -0400 Joe Maimon <jmaimon@ttec.com> wrote:
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?
Oh, right. Handling that would be slightly complex. FR itself (as opposed to modules) would have to understand State. So if a packet came in with State, it could decode the first byte or 2 and decide whether to hand it to an old or new instance of a module. The refcount idea would also be invalid in this case, although maybe it's still useful in general (not sure). But for multi-packet transactions, the refcount could go to 0 yet there would still be pending transactions for an old module instance. I guess a first version could simply ignore that problem.
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.
Well the problem here is orthogonal to SQL AFAICT. -frank