On 23.08.2006, at 16:55, Vlad Seryakov wrote:
Then we can just go through the code(fastpath, log) and change it
so it
copies config at startup into local variables (as in server.c) if that
particular code does not care about realtime changes. This way it will
be a compromise between locking and performance.
I believe this is possible.
The config user (in that case the fastpath or log code)
should actually decide what is more important: reaction
to config changes or absolute avoidance of locking
wherever possible.
In some cases, reaction to config-chage is pretty
difficult, if possble at all! In such cases, getting
the config value once and never asking for it again
is quite natural.
In some cases (like Stephens example with log) it is
actually desireable to react to changes instantly.
Actually, here the locking would be unavoidable.
But, even then, in this particular case, we have
ns_logctl which would for example be used to query
the config and update private log data once and then
have other log calls examine that data w/o locking.
I'm interesed to find out what do you think about
speeding up the set operation by a help hash-table?
This would minimize the time the lock is held and
would therefore lower the impact of locking altogether.
Cheers
Zoran
