Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Stephen D. <sd...@gm...>]

On 6/25/06, Vlad Seryakov <vl...@cr...> 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.