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

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

On 6/30/06, Vlad Seryakov <vl...@cr...> wrote:
> To mimic Tcl variables usage or any memory access operations, by having
> _set, _get, _exist, _unset with additional _eval will make it complete
> and will allow to use by the developer as he sees fit. These are basic
> operations, on top of that a developer can build different systems, not
> just one way. It is development tool, not complete system, we can never
> anticipate all possible usages of cache API, so providing low-level
> primitives in my opinion is good direction.


_set, _get and _exists aren't cache primitives because they're not
thread safe.


> >
> > But, do not get me wrong. I'm not in favour of stripping functionality.
> > As far as I', concerned, ns_cache API can consist of only three
> > calls:
> >
> >     ns_cache_create
> >     ns_cache_eval
> >     ns_cache_flush
> >
> > More is not needed for the "usual" cache operation. Now, one
> > can imagine adding some operations on the cache vaules directly
> > like
> >
> >     incr
> >     llength
> >     lindex
> >
> > and atomic operations lile
> >
> >     set
> >     exists
> >     get


These aren't atomic.

For example, after ns_cache_exists returns the value may exist or not
due to cache flush, expiry, etc., you really don't know.


> > which is all allright but in some "sense" diverts from the
> > base idea of cache: just temporary store values resulting
> > from hard caclulations.
>
>
> Tcl variable fall into this category as well and has more operations and
> other tools to work with. Why limiting cache, in some sens it is shared
> variables by more than one thread with locking, expiration if set, and
> timeouts if set. what is wrong to treat cache as more powerfull tool.


Tcl variables work in a completely different environment, they are not
intended to be thread safe.