memcache(3) 1.2.0 released...

[John McCaskey]

I notice you started strdup'ing the key's... but you didn't start
freeing them :)

Patch to fix insuing memory leak attached...  I made the decision that
even if the free on delete flag is set to off, then still free the key,
just not the value.  This way it doesn't create memory leaks in
previously written code.  Could be you want it the opposite and everyone
needs to update their code to free the key if they set the flag...

Also, I included in the patch commenting out the warnx() calls on
mcm_server_activate.  When you do a mc_server_activate_all() these
warnings are always going to occur unless all of your servers were down,
as such I get a huge amount of warning output that I don't want.  I
figure no one else would want this either.

On Sun, 2005-01-09 at 17:45 -0800, Sean Chittenden wrote:
> Howdy.  Thought a few folks would be interested in the 1.2.0 release.
> 
> 	http://people.FreeBSD.org/~seanc/libmemcache/
> 
> There are a few significant changes that people may want to note.
> 
> *) Hashing of keys is only performed when there is more than one live 
> server.
> 
> *) As a result of the above, hashing of keys is no longer done at 
> mc[m]?_req_add() time.  If requests are being prepared ahead of time to 
> avoid latency, one can do 'res = mc[m]?_req_add(req, key, keylen); 
> res->hash = mc[m]?_hash_key(key, keylen);' and then an mc[m]?_get() 
> when needed.
> 
> *) Add mc_server_add4() which takes a 'hostname:port' argument.
> 
> *) Added an internal strdup(3) function that uses the atomic malloc 
> function if one is provided (otherwise the normal malloc).
> 
> *) Added various functions and macros for version detection.  See the 
> ChangeLog for details.
> 
> The API changed slightly and the ABI most certainly did, but thee 
> library version has been bumped to 1.2 as well to account for this.  If 
> anyone has any problems, please let me know.
> 
> At this point I'm going to begin working in the direction of the 
> scatter/gather method of performing multi-get requests.  This effort 
> will be the main focus of the 1.3 version unless someone else comes up 
> with some feature requests they'd like to have added.  -sc
> 
-- 
John A. McCaskey
Software Development Engineer
Klir Technologies, Inc.
johnm at klir.com
206.902.2027
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memleak-fixed.patch
Type: text/x-patch
Size: 963 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/memcached/attachments/20050112/b7d889b0/memleak-fixed.bin