From: Zoran V. <zv...@ar...> - 2006-08-23 15:06:07
|
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 |