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

From: Date: Mon, 28 Dec 2009 07:10:38 +0000
Subject: Re: [APC-DEV] Re: [PECL-CVS] svn: /pecl/apc/trunk/ apc_cache.c apc_cache.h php_apc.c php_apc.h
References: 1 2 3  Groups: php.apc.dev 
Request: Send a blank email to php-apc-dev+get-254@lists.php.net to get a copy of this message
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.

« previous php.apc.dev (#254) next »