On 7/1/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
Am 01.07.2006 um 18:17 schrieb Gustaf Neumann: > Zoran Vasiljevic schrieb: >> For my *personal* taste, the API is way too large >> but what I do not use, I do not care for. >> I have nothing against having all this in core >> and I have nothing against maintaining this >> code in future, if the need arises. >> >> > The ns_cache interface resembles much similarity to the nsv interface. > Essentially, it looks to me > as an outsider that the main difference to nsv are the options for > pool > size and timeout. Has anyone > considered to converge nsv and ns_cache by e.g. providing storage > pools > with size and timeout > to nsv (binding nsv varnames to storage pools)? Also, the eval > subcommand makes sense for > nsv. Absolutely! This is what I told Vlad in one of the previous emails. The only *real* difference is the time/size pruning of ns_cache what nsv's do not have. I havent examined what would be needed for this thing. Also I wanted to port thread::tsv interface from the Tcl threading extension to NS. In that effort I could examine if this would be feasible or not. What do other people think?
Well, nsv, cache, Tcl arrays are all very similar -- key/value associations. But it's the small differences which really matter. Caches are not just size/time limited, they're also assumed to cache something (!) which is expensive to compute, hence the -timeout switch and the complicated locking to ensure that should two threads try to compute a cache value at the same time, one waits for the other to do the hard work. Stats only really make sense for caches. It's not an error for a cache value to be missing -- caches cache *some* of the data, hopefully the most frequently used. You can use the stats to figure out if this is happening or not. nsv on the other hand are server-wide variables. You might say that Tcl arrays are broken because the values don't expire... :-)
