libmemcache, various minor questions

[Sean Chittenden]

> external/libmemcache/libmemcache.c:208: warning: assignment discards
> qualifiers from pointer target type

The correct fix is to have the iovec structure that writev(2) and 
readv(2) accept a const char * pointer instead of a char *.  When 
assigning a const char * string, these warnings pop up.  I experimented 
around with using strdup(3) as a way of avoiding these warnings, but 
there was a dreadful performance hit (50K/s -> 25K/s).  gcc(1) does 
something smart with const strings over volatile strings.  Patches 
welcome if there's a better way to handle this.  Casting doesn't work 
in gcc 3.4: it's finally starting to sport a brain.

> type warnings, looks like all it takes to avoid these is to explicitly
> cast away the const qualifier.  Is there a reason why this isn't being
> done (doesn't work on other platforms maybe?)?  I know the warning is
> nothing to worry about, but I just hate seeing them in my otherwise
> warning free code :)

Yeah, I'm not too happy about it, but given the performance hit of the 
alternative, I'll settle for the warnings.  I almost throw in some 
#warning bits to let the user know these are cool.  I couldn't find the 
gcc(1) flag that let me suppress them either.  :(

> Also, it looks like the examples on the libmemcache page need some
> updating, the order of arguments to mc_aget for example is incorrect!

Heh, let me go fix that.

> And finally, I seemed to have alot of trouble using mc_aget with the
> correct value not being returned, and ultimately freeing the memory
> resulting in stack corruption.  I need to isolate out my code and try 
> to
> reproduce this with a simple test case, if I can I'll report back.  
> When
> I swithced to using mc_req_add, mc_get, etc, I had no further issues.

I pushed out a bogus version of libmemcache(3) that used && instead of 
|| in a critical bit of code...  you may be getting bit by this.

> Any known issues with mc_aget I should be aware of?

I added mc_aget(3) as a convenience function when I first thumped 
libmemcache(3) out...  I'm not opposed to removing it, to be honest, 
but too many people seem to like it.  :(


I'll probably push out another change here that includes the ability to 
support multiple memory contexts in the same process space that way 
PHP, apr, Ruby, PostgreSQL, etc., can all use the same library 
invocation without having to worry about stomping on each other's 
allocation routines.  The API for single memory context invocation will 
remain the same, but if you need multiple contexts, you'll have to use 
a slightly different API, but nothing that sed(1) + a little hacking 
can't fix.

-sc

-- 
Sean Chittenden