libmemcache, various minor questions
johnm at klir.com
Mon Dec 6 16:56:07 PST 2004
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
> > 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.
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm at klir.com
More information about the memcached