Be it. I do not have anything against. Developers should be warned
though that exists/get or exists/set or any combianation of those
must be protected by external mutex to avoid race conditions.
In that case, one should/would add something like:
ns_cache_lock cachename {
do whatever with the cache
}
This is ns_cache_eval
which needs to be a recursive lock, OR
ns_cache_lock cachename
ns_cache_unlock cachename
in which case developer should exercise caution
to make sure to unlock the cache at all costs even
in case of Tcl error happening between lock/unlock calls.
So. This is what I must add to it.
It is not necessary, we have ns_cache_eval to such things.
_set will do it with locking, _get will return consistent value as well.
The only place when it needs when somebody will do
if { ns_cache_exist cache key] } {
...
ns_cache_....
...
}
But again, it could perfectly correct in his case if cache entry never
got flushed, but system need to act on his appearance, so check for
existence will notify caller that he may do some thing already, so i
would let developer decide, but putting notes in the docs would be of
course helpful for someone who just started learning programming with
threads and locks.
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
