antirez/hiredis — Issue #79: Change in redisReply memory ownership for redisAsyncCommand
Author: ewencp
Created: 2012-01-28 00:47:45+00:00
State: open

Commit 3ce8d5b08b5d13f550983048ee89293e9f6897ca changed the behavior of async callbacks by always freeing memory after the callback instead of leaving it to the callback. This change may not have been noticed since it looks like the samples using the async API weren't even freeing memory properly before the change.

Either this was intended, in which case the readme should be updated to reflect the change in behavior, e.g.:

```
diff --git a/CHANGELOG.md b/CHANGELOG.md
index d41db8a..73e46b2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -14,3 +14,6 @@

* See commit log.

+* The asynchronous API now free's replies automatically: the callback
+ does not own the redisReply and should not call freeReplyObject on
+ it.
diff --git a/README.md b/README.md
index 6cf7b1c..a58101c 100644
--- a/README.md
+++ b/README.md
@@ -286,7 +286,8 @@ is being disconnected per user-request, no new commands may be added to the outp
returned on calls to the `redisAsyncCommand` family.

If the reply for a command with a `NULL` callback is read, it is immediately free'd. When the callback
-for a command is non-`NULL`, it is responsible for cleaning up the reply.
+for a command is non-`NULL`, the memory is free'd immediately following the callback: the reply is only
+valid for the duration of the callback.

All pending callbacks are called with a `NULL` reply when the context encountered an error.

```

If this was *not* intended, the fix is probably more substantial since the commit that made the relevant change suggests the pub/sub code uses this code path and probably relies on it to free the replies. However, I don't haven't used the pub/sub code at all or looked at its implementation, so I am not certain about that.