HUP handling: a thought

[Alan DeKok]

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