On 6/25/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> > If you need to test for existence, you're doing something wrong. > Between the test and the action taken depending on the result, the > result could have changed. > > However: > > ns_cache_eval $cache $key {error "no entry available"} > > You can catch the error and do whatever, no new entry will be created.Again, you assuming only one way of using caches, in my case i am not afraid what happens in between because, i just need to know if somebody put anything in the cache, similar to flag. Very simple test, and does not need to generate and cache error exception which will make Tcl doe look ugly. That's why we have info exists in Tcl instead of error handling if we need to test existence. > >> And why ns_cache_eval -force is not racy but than ns_cache_set is if >> they do the same thing, why cryptic API flags instead of clear >> functions. If have them for nsv_ for example. > > > It depends how you use them. The use case of pre-filling a cache in > bulk at start up for example might be a good use of this. In combo > with _info is not. The -force switch was a ~3 line addition. Right, so it is up to the developer to decide how to use primitive cache routines, and i never said i use _info first then _set next, but i can see it may be used in environment where serialized jobs are running in different threads and i need to know what previous job have done. In this case _info then _set or _get is pretty valid, it uses cache as a storage in non-concurrent environment.
Communication between serialized threads doesn't sound like a cache to me. Anyway, the idea is that if you need to do weird stuff it should be possible, and an ns_cache_info equivalent can be writen in ~3 lines of Tcl.
