Hiredis can handle multi bulk replies with a fixed (hardcoded) level of
nesting. This should be changed in the future in order to avoid
hardcoded limits. As a quick fix this commit moves the max nesting from 2
to 7, so that there are no problems when processing replies from the SLOWLOG
command, from Redis Sentinel, or generated by Redis Lua Scripts (that are
allowed to generate replies with any level of nesting).
Hiredis used to free unused redisReader buffers bigger than 16k. Now
this limit is configurable (see the documentation updated by this commit)
in order to allow working with big payloads without incurring to speed
penalty.
This reverts commit 77540aa316. The change
in buffer strategy is too large to put in a minor release. It is put in
a separate branch in the meantime, so it can be refined and released
together with a minor version bump.
This is done by only truncating the read buffer once a full reply has
been read. The buffer is no longer truncated halfway through reading a
reply. In addition: pass offset/length of protocol and content via the
read tasks.
To make sure that these functions can also be called from functions
other than command callbacks, the flag IN_CALLBACK is introduced that
holds whether the context is currently executing a callback. If so,
redisAsyncFree() and redisAsyncDisconnect() should delegate their task
to the reply processor to avoid segfaults.
When no reply object functions are defined, the reply type integer is
returned from redisGetReply(). This sets the *reply argument to the
consumed reply, where 0 means that it was not possible to consume a full
reply. With REDIS_REPLY_ERROR having the same value, there is no way to
tell the difference between an error reply and not consuming a reply.
When there is an I/O error, errno should be used to find out what is
wrong. In other cases, errno cannot be used. So, use an explicit type in
Hiredis to define the different error scenarios that can occur.
