1) For :1113 I noticed if I added the item_remove diff like you
suggested, it ends up returning the memory identifier of the new
variable that is always the same in memory vs address of actual item
pulled from item_get. Suggestions to fix? Try it yourself, when you
use the same itmp variable on it and set a few items over and over
again. It will usually always be same memory address (even if data
changes).
2) Yeah I expanded item_alloc because the way memcache reads through
the loop of data sent. Originally I did it the way I sent you, but ran
into an issue with existing clients. I noticed that memcached would
throw an error right when memcache read the cas command (which is
OK..). But all of our commands (add,replace,set) wait until
complete_nread occur before returning either STORED/NOT_STORED to be
compatible with existing clients.
I have no problems reverting back to the original method if you might
have a solution for that?
Chris Goffinet
[EMAIL PROTECTED]
On Sep 16, 2007, at 11:41 PM, Dustin Sallings wrote:
On Sep 16, 2007, at 22:25, Chris Goffinet wrote:
Sorry for getting this in late, here is the memcache cas patchset I
did with the help of Dustin Sallings. I'll try to get the pecl
memcache diff out too later this week, just super busy right now.
It's prototype, but works and I know can be cleaned up :-) If I get
time I'll do that too.
Couple of comments on this version:
1) You've got an item_get that doesn't have a corresponding
item_remove (:1113)
2) I don't completely understand why item was expanded for an
identifier. Its usage seems to suggest it's a parameter being
passed into store.
3) Can no longer distinguish between a missing record (need to
add) or a missed identifier (need to refetch and try again).
Both #2 and #3 seem to have something to do with the new parameter
on item_alloc. Is it possible to avoid this API change? It's not a
*huge* deal, but it causes a forward compatibility issue with my
binary patches on my single patch stack. If you could avoid the API
change, I wouldn't have to maintain two different versions. :)
--
Dustin Sallings
