libmemcache, various minor questions
John McCaskey
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
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
More information about the memcached
mailing list