On 15.10.2007, at 20:37, Stephen Deasey wrote:
>
> One problem is that there seems to be a lot of memory allocation and
> copying going on, even on the fast path. For example, NsConf_GetBool()
> does three mallocs, a couple of copies, conversion back and forth
> between string and int rep, two hash lookups and a lock/unlock. It's
> not exactly (opt & FOO_OPT) :-(
This all is true in the current implementation just
because I was lazy... The important part where you
need to look at is the:
ConfGetParam(section, key, &defpar, &outpar);
This one we must/should take apart. Even here we have
some headroom.
>
> Another problem is that the model is extremely basic. It seems to be
> identical to nsv (with different locking) so the only way to have
> dynamic configuration is to do this:
>
> AtRuntime()
> {
> if (ConfigGet("enabled")) {
> ...
> }
> }
>
>
> - This will be a problem for some code because it's too slow.
It very different from nsv. Locking is completely different.
The only similarity is that it stores key/value pairs.
>
> - Some configuration parameters depend on other ones or on some
> computation like converting units. ATM this is done once at startup.
> But with this scheme it would have to be inline with the code that
> used the param (or perhaps wrappers..).
True. But, again, this would be done only once, as I cache
the values in the per-thread private hash table.
>
> - Some changes in config values should trigger other code to run -- it
> is an event, it is not polled. For example, some threads might need
> killed off or created within a pool, or a proc should be scheduled.
By all means. Bu this is not in the scope of the config module,
rather the "user" code. If the user-code is written so that it
reacts to changes of the config, then there is no problem.
At the moment no code does that because the config is read-only.
>
> - One of the problems mentioned was inventorying config params. For
> example, some config params are guarded behind a check for 'enabled'
> -- if it's not enabled the other params won't be checked, and they
> remain hidden. I guess this module doesn't help with this, maybe it
> shouldn't..?
This is the functionality that I did not handle at all. The emphasis
was to create read/write config more/less with the same functionality
as the current one.
>
>
> One way of looking at it might be that this will not handle all config
> situations. I think the problem with that is:
>
> 1: It is confusing. We are saying: config is read write. But when you
> write some config params, nothing changes. It is doubly confusing
> because some of those params *will* be changeable, but only by calling
> ns_fooctl.
This is true. If the rest of the code is not programmed with the
notion of changeable config, there will be "confusing" situations.
>
> 2: This scheme would nicely handle non performance critical key/value
> config called from Tcl code. But if you can already do that with
> nsv...?
Well, not really. This needs to be also accessible from C and from
various plugin-modules.
>
>
> I still agree that a more runtime configurable server is desirable.
One thing to remember: if we set the funtional-bar too high we will
not achieve much on the short/midterm.
What I see is that in order to make the config writable, all kind of
parts in the server needs to be rewritten in order to gain benefit
from it (less important) and behave "logically" (more important).
Given number of such places that would be potentially changed are
so high that I will not attempt to do so. Simply because of the lack
of time.
Do you have some other idea how (if) we should build the chnageable
config? It seems pretty silly to me that we need to restart the server
to change some marginal parameter... In the 21. century...
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
