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:
> 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.


As I understood this I thought the user wanted this to simplify his API approach when just checking if something was in the cache.  So I think that I'm fine with this function being added to APC, regardless of it's speed difference.  In some cases this could be faster, as I think we do spend a good bit of time copying and setting up zval structures if the data is an array, longer string, or that we are just fetching a large number of items.

-shire