On 22.08.2006, at 22:13, Stephen Deasey wrote:
I don't see how you will handle the locking... :-(
I imagine the entire configuration tree being implemented
as a global master (in-memory) tree, close to the DOM.
Actually, it can be really a DOM structure (see below for
the alternative).
I'm assuming that reads (queries into the) config tree will
be a majority of operations whereas writes will be occasional.
I expect this to be far more than 80/20 ratio in favour
of readers vs. writers.
Every thread will have a copy (in TSD) of the master tree
structure and will use it to read config parameters from.
The master tree structure will have a single global
mutex and associated epoch counter.
A thread wanting to read some config param will have
to lock the mutex, examine the epoch and compare it with
the epoch of the copy of the tree it's holding in the TSD.
If there is a match, the mutex is released.
If there is no match, the entire private copy is trashed,
new copy is made and the mutex is released.
In any case, the result is returned from the *local* copy.
A thread wanting to change a parameter will lock the mutex,
bump the epoch, change the parameter in the master copy,
then copy the entire master DOM to its private storage and
release the mutex.
Having the configuration storage in tree means that we can
easily serialize it to XML and store it as a plain file
on the filesystem. This can be done either:
never
at server shutdown (or some signal perhaps)
periodically over some scheduled procedure
Alternatively, one can attach some kind of permanent
persistence (a (g)dbm file for example) to the tree
so every modification is immediately saved.
Due to the assumption that readers will be far more
frequent than writers, so the tree copying between
the master and private copy will be very rare, all we
have to "accept" would be a short lock on a global mutex
in order to examine the epoch counter and decide wether
our local copy is up-to-date or not.
Alternatively, the DOM tree can be replaced by a combination
of hash-tables and C-structures. Each ns_section will
effectively be a hash table of parameters with a parameter
being a simple C-struct. Also, there will be one global hashtable
needed to resolve ns_section names to hash-tables holding parameters.
I doubt however that this would be any faster then a good DOM
implementation.
This is not a "piece of cake" project hence I would like
to hear some comments before proceeding.
Cheers
Zoran
