On 23.08.2006, at 13:01, Zoran Vasiljevic wrote:
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.
I see... this is more-less the nsv as we have it today. Why wouldn't we making nsv interface public and use it for configuration store? After all, the code is there and is well tested. We might need to tweak some pieces but, in principle, this is it. I would need to refresh my view of nsv locking but generally it uses fixed number of buckets to avoid everybody locking the same global mutex. Increasing number of buckets lowers the contention. The only part we need to think about is actual parameter storage as this will not be a plain value, but also some housekeeping info like type, ranges etc, in addition. Given relatively fast lookup and relatively cheap locking, we would not need to have private and shared copies. I believe just one shared copy would be perfectly OK. Hm? What do you mean? Cheors Zoran
