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

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.

Cheers,
Gopal
-- 
The difference between insanity and genius is measured by success.