libmemcache, various minor questions

[John McCaskey]

On Mon, 2004-12-06 at 16:46 -0800, Sean Chittenden wrote:
> > 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.
> 

Fair enough, I definately don't want to see a dreadful performance
hit.  

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

Ok, I'll just avoid the use of mc_aget in the future, but I just updated
to the latest code off your page and I can still reproduce the issue, so
maybe its something to look into.  Or maybe I'm using it wrong?  See my
previous response with code that I use to repro the issue.

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

That sounds great!  Thanks for all the work you've already put into
this.  We are looking at using memcached/libmemcache for a pretty
substantial project and apart from these few minor issues everything is
looking very good so far.

> 
> -sc
> 
-- 
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm at klir.com
206.902.2027