You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These results are not completely fair, because of the usage of different semantics in the
65
65
APIs; however they are still interesting, as they are using different
66
66
underlying event libraries ([Boost::ASIO](http://www.boost.org/doc/libs/release/libs/asio/) vs [libev](http://software.schmorp.de/pkg/libev.html)) as well as redis protocol
67
67
parsing libraries (written from scratch vs [hiredis](https://github.com/redis/hiredis))
68
68
69
+
`(*)` bredis with drop_result policy, i.e. replies from redis server are
70
+
scanned only for formal correctness and never delivered to the caller.
71
+
72
+
69
73
## Work with the result
70
74
71
75
The general idea is that the result of trying to parse a redis reply can be either: not enough data, protocol error (in an extreme case) or some positive parse result. The last one is just **markers** of the result, which is actually stored in the *receive buffer* (i.e. outside of markers, and outside of the bredis-connection).
@@ -386,7 +390,7 @@ boost::asio::spawn(
386
390
## Steams
387
391
388
392
There is no specific support for streams (appeared in redis 5.0) in bredis,
389
-
they are just usual `XADD`, `XRANGE` etc. commands and corresponding replies.
393
+
they are just usual `XADD`, `XRANGE` etc. commands and corresponding replies.
0 commit comments