Frank Cusack wrote:
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.)
That is one thought, which requires everything to be tied to a REQUEST* (not a bad idea, in many respects).
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.
Simpler: each config has a timestamp of when it is active, and when it becomes stale. The REQUESTs already have a timestamp, too. Then, say 30s after the new config becomes active, start scanning the request list for REQUESTs that use the old config. If there are none, clean up the old config. i.e. Garbage collection is often cheaper than refcounts. ISC DHCPD uses refcounts for everything. They're a nightmare to keep track of, and they have *significant* performance overhead.
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.
If the REQUEST* has a config_t, the proxy replies will pick that up. The EAP module can also be updated to add a config_t to the state it keeps.
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.
Yes. There are two problems: 1) dynamically changing data structures as they are being used 2) how to tell the server which data structure to change. (1) has to be solved before (2) becomes useful. (2) can be done by any number of means. The reason I've been leaning towards and SQL-like interface is because I don't want to re-invent yet another CLI. We can always write a simple program that translates a sane (i.e. humanly readable) CLI to SQL. The utility of SQL comes in leveraging the large amount of tools that are ready-made to perform data manipulation. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog