Re: [APC-DEV] Re: [PECL-CVS] svn: /pecl/apc/trunk/ apc_cache.c apc_cache.h php_apc.c php_apc.h

Gopal V wrote: > Rasmus Lerdorf wrote: >> shire wrote: >>> hrm, yeah I don't think we can get away without the lock here, simply >>> because of the (*slot)->next/key type pointer usage. I believe the >>> structure would allow that to be an invalid pointer if it's still in the >>> process of being updated, inserted, removed etc. >> >> I guess that is true. I was thinking even if a slot is deleted, it >> would be on the pending list and the *next would still be valid and take >> us back into the cache entries, but that is only true if the ref_count >> is non-zero, otherwise the entry is destroyed right away. With the lock >> though, apc_exists is only going to be faster than apc_fetch() by a >> memcpy (or many memcpys for an array). > > The issue with such functions is that it sets up an easy race condition > in user land. > > if(!apc_exists(...)) { > apc_store(); > } > > Which is nearly identical to the user cache slam I keep talking > about. They're nice in some api sense of the word, but I fail to > see how someone is going to use this one in any better way than > the old fetch or store/add. No, that wouldn't be the use case because that is exactly what apc_add() is for. apc_exists() is a slightly faster way to check if something is in the cache and it doesn't suffer from the value=false problem using apc_fetch() has when used for this. -Rasmus