On 23.08.2006, at 19:41, Mike wrote:
"Two" has to remain with-case because it is a value, but its intent is
to point the reader of the config at ns/two, which is now lowercased.
Urks! I would never come to that usage pattern,
but you are absolutely right.
Another reason we must preserve the
On 8/23/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 23.08.2006, at 18:35, Mike wrote:
> I do have one concern with this change - what happens when the value
> (where case must be preserved) for some key is actually the name of
> another section or key? I do not have enough experience to
On 23.08.2006, at 19:20, Rick Cobb wrote:
Potential objection to normalizing the case: ns_params for CGI
environment variables. Environment variable names are case sensitive,
and it's perfectly possible that there are applications that use
lower-case names for these. Would require changing ns
Potential objection to normalizing the case: ns_params for CGI
environment variables. Environment variable names are case sensitive,
and it's perfectly possible that there are applications that use
lower-case names for these. Would require changing nscgi to something
more like
Ns_param set {{vari
On 23.08.2006, at 18:23, Zoran Vasiljevic wrote:
All measurements are done on my Mac PB 1.5GHZ powerpc.
WRONG! That was on an Linux box (SuSE9.1)
devlinux# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athl
On 23.08.2006, at 18:35, Mike wrote:
I do have one concern with this change - what happens when the value
(where case must be preserved) for some key is actually the name of
another section or key? I do not have enough experience to tell if
this is ever a problem, but I am not sure how this si
On 8/23/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 23.08.2006, at 17:20, Andrew Piskorski wrote:
> That's only necessary to preserve the current ns_config
> case-insensitivity, right? Wouldn't it be easier to just canonicalize
> the key values on both write and read? E.g., create a wr
On 23.08.2006, at 17:11, Vlad Seryakov wrote:
In the case when ns_set has only few items, sequential search can be
much faster than hash overhead, so i am not sure about this one
Most interesting:
lexxsrv:nscp 3> ns_set create
d0
lexxsrv:nscp 7> for {set i 0} {$i < 100} {incr i} {ns_set put
On 23.08.2006, at 17:20, Andrew Piskorski wrote:
That's only necessary to preserve the current ns_config
case-insensitivity, right? Wouldn't it be easier to just canonicalize
the key values on both write and read? E.g., create a wrapper around
nsv which forces all keys to all lowercase. Then
On Wed, Aug 23, 2006 at 05:05:55PM +0200, Zoran Vasiljevic wrote:
> 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.
That's only nec
On 23.08.2006, at 17:11, Vlad Seryakov wrote:
In the case when ns_set has only few items, sequential search can be
much faster than hash overhead, so i am not sure about this one
Yes. This is true. But how would you know?
Say you have 100 element set and the thing
you are looking for is on t
Agree on up-to-the clinet policy of config usage
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.
In the case when ns_set has only few
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 a
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.
Zoran Vasiljevic wrote:
On 23.
On 23.08.2006, at 16:17, Vlad Seryakov wrote:
Looking thru the code i see that mostly only fastpath and log uses
NsConfig reads in real time, all others are copy values into local
structures. funny, but these who uses config are performance critical
and will introduce lock contention because th
On 23.08.2006, at 14:46, Zoran Vasiljevic wrote:
Why wouldn't we making nsv interface
public and use it for configuration store?
Eh... there is always yet-another gotcha!
Because... the nature of the config interface
is to allow case-insensitive or case sensitive
lookups. Hence, sets are use
Looking thru the code i see that mostly only fastpath and log uses
NsConfig reads in real time, all others are copy values into local
structures. funny, but these who uses config are performance critical
and will introduce lock contention because thet are figthing for the
same config values.
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
On 23.08.2006, at 13:01, Zoran Vasiljevic wrote:
The master tree structure will have a single global
mutex and associated epoch counter.
To reduce contention on that mutex, one can compute
a simple checksum of the section name and use this to
address fixed number of buckets, each holding one
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
20 matches
Mail list logo
