From 0501538dc57ba5d4dcf4f963e99dba3b5b58afba Mon Sep 17 00:00:00 2001 From: michael-grunder Date: Fri, 24 May 2024 11:56:54 -0700 Subject: [PATCH] Readme renaming --- libvalkey/README.md | 165 ++++++++++++++++++++++---------------------- libvalkey/test.c | 2 +- 2 files changed, 83 insertions(+), 84 deletions(-) diff --git a/libvalkey/README.md b/libvalkey/README.md index 4635550a..def2cbe5 100644 --- a/libvalkey/README.md +++ b/libvalkey/README.md @@ -10,7 +10,7 @@ Libvalkey is a minimalistic C client library for the [Valkey](https://valkey.io/ It is minimalistic because it just adds minimal support for the protocol, but at the same time it uses a high level printf-alike API in order to make it much higher level than otherwise suggested by its minimal code base and the -lack of explicit bindings for every Redis command. +lack of explicit bindings for every Valkey command. Apart from supporting sending commands and receiving replies, it comes with a reply parser that is decoupled from the I/O layer. It @@ -40,7 +40,7 @@ context is where Libvalkey holds state for a connection. The `valkeyContext` struct has an integer `err` field that is non-zero when the connection is in an error state. The field `errstr` will contain a string with a description of the error. More information on errors can be found in the **Errors** section. -After trying to connect to Redis using `valkeyConnect` you should +After trying to connect to Valkey using `valkeyConnect` you should check the `err` field to see if establishing the connection was successful: ```c @@ -64,16 +64,16 @@ valkeyOptions opt = {0}; /* One can set the endpoint with one of our helper macros */ if (tcp) { - REDIS_OPTIONS_SET_TCP(&opt, "localhost", 6379); + VALKEY_OPTIONS_SET_TCP(&opt, "localhost", 6379); } else { - REDIS_OPTIONS_SET_UNIX(&opt, "/tmp/valkey.sock"); + VALKEY_OPTIONS_SET_UNIX(&opt, "/tmp/valkey.sock"); } /* And privdata can be specified with another helper */ -REDIS_OPTIONS_SET_PRIVDATA(&opt, myPrivData, myPrivDataDtor); +VALKEY_OPTIONS_SET_PRIVDATA(&opt, myPrivData, myPrivDataDtor); /* Finally various options may be set via the `options` member, as described below */ -opt->options |= REDIS_OPT_PREFER_IPV4; +opt->options |= VALKEY_OPT_PREFER_IPV4; ``` If a connection is lost, `int valkeyReconnect(valkeyContext *c)` can be used to restore the connection using the same endpoint and options as the given context. @@ -84,12 +84,12 @@ There are several flags you may set in the `valkeyOptions` struct to change defa | Flag | Description | | --- | --- | -| REDIS\_OPT\_NONBLOCK | Tells hiredis to make a non-blocking connection. | -| REDIS\_OPT\_REUSEADDR | Tells hiredis to set the [SO_REUSEADDR](https://man7.org/linux/man-pages/man7/socket.7.html) socket option | -| REDIS\_OPT\_PREFER\_IPV4
REDIS\_OPT\_PREFER_IPV6
REDIS\_OPT\_PREFER\_IP\_UNSPEC | Informs hiredis to either prefer IPv4 or IPv6 when invoking [getaddrinfo](https://man7.org/linux/man-pages/man3/gai_strerror.3.html). `REDIS_OPT_PREFER_IP_UNSPEC` will cause hiredis to specify `AF_UNSPEC` in the getaddrinfo call, which means both IPv4 and IPv6 addresses will be searched simultaneously.
Libvalkey prefers IPv4 by default. | -| REDIS\_OPT\_NO\_PUSH\_AUTOFREE | Tells hiredis to not install the default RESP3 PUSH handler (which just intercepts and frees the replies). This is useful in situations where you want to process these messages in-band. | -| REDIS\_OPT\_NOAUTOFREEREPLIES | **ASYNC**: tells hiredis not to automatically invoke `freeReplyObject` after executing the reply callback. | -| REDIS\_OPT\_NOAUTOFREE | **ASYNC**: Tells hiredis not to automatically free the `redisAsyncContext` on connection/communication failure, but only if the user makes an explicit call to `valkeyAsyncDisconnect` or `valkeyAsyncFree` | +| VALKEY\_OPT\_NONBLOCK | Tells libvalkey to make a non-blocking connection. | +| VALKEY\_OPT\_REUSEADDR | Tells libvalkey to set the [SO_REUSEADDR](https://man7.org/linux/man-pages/man7/socket.7.html) socket option | +| VALKEY\_OPT\_PREFER\_IPV4
VALKEY\_OPT\_PREFER_IPV6
VALKEY\_OPT\_PREFER\_IP\_UNSPEC | Informs libvalkey to either prefer IPv4 or IPv6 when invoking [getaddrinfo](https://man7.org/linux/man-pages/man3/gai_strerror.3.html). `VALKEY_OPT_PREFER_IP_UNSPEC` will cause libvalkey to specify `AF_UNSPEC` in the getaddrinfo call, which means both IPv4 and IPv6 addresses will be searched simultaneously.
Libvalkey prefers IPv4 by default. | +| VALKEY\_OPT\_NO\_PUSH\_AUTOFREE | Tells libvalkey to not install the default RESP3 PUSH handler (which just intercepts and frees the replies). This is useful in situations where you want to process these messages in-band. | +| VALKEY\_OPT\_NOAUTOFREEREPLIES | **ASYNC**: tells libvalkey not to automatically invoke `freeReplyObject` after executing the reply callback. | +| VALKEY\_OPT\_NOAUTOFREE | **ASYNC**: Tells libvalkey not to automatically free the `redisAsyncContext` on connection/communication failure, but only if the user makes an explicit call to `valkeyAsyncDisconnect` or `valkeyAsyncFree` | *Note: A `valkeyContext` is not thread-safe.* @@ -97,10 +97,10 @@ There are several flags you may set in the `valkeyOptions` struct to change defa The following socket options are applied directly to the underlying socket. The values are not stored in the `valkeyContext`, so they are not automatically applied when reconnecting using `valkeyReconnect()`. -These functions return `REDIS_OK` on success. -On failure, `REDIS_ERR` is returned and the underlying connection is closed. +These functions return `VALKEY_OK` on success. +On failure, `VALKEY_ERR` is returned and the underlying connection is closed. -To configure these for an asynchronous context (see *Asynchronous API* below), use `ac->c` to get the valkeyContext out of an asyncRedisContext. +To configure these for an asynchronous context (see *Asynchronous API* below), use `ac->c` to get the valkeyContext out of an valkeyAsyncContext. ```C int valkeyEnableKeepAlive(valkeyContext *c); @@ -125,7 +125,7 @@ Set the `TCP_USER_TIMEOUT` Linux-specific socket option which is as described in ### Sending commands -There are several ways to issue commands to Redis. The first that will be introduced is +There are several ways to issue commands to Valkey. The first that will be introduced is `valkeyCommand`. This function takes a format similar to printf. In the simplest form, it is used like this: ```c @@ -144,7 +144,7 @@ of the string: reply = valkeyCommand(context, "SET foo %b", value, (size_t) valuelen); ``` Internally, Libvalkey splits the command in different arguments and will -convert it to the protocol used to communicate with Redis. +convert it to the protocol used to communicate with Valkey. One or more spaces separates arguments, so you can use the specifiers anywhere in an argument: ```c @@ -165,63 +165,62 @@ was received: ### RESP2 -* **`REDIS_REPLY_STATUS`**: +* **`VALKEY_REPLY_STATUS`**: * The command replied with a status reply. The status string can be accessed using `reply->str`. The length of this string can be accessed using `reply->len`. -* **`REDIS_REPLY_ERROR`**: - * The command replied with an error. The error string can be accessed identical to `REDIS_REPLY_STATUS`. +* **`VALKEY_REPLY_ERROR`**: + * The command replied with an error. The error string can be accessed identical to `VALKEY_REPLY_STATUS`. -* **`REDIS_REPLY_INTEGER`**: +* **`VALKEY_REPLY_INTEGER`**: * The command replied with an integer. The integer value can be accessed using the `reply->integer` field of type `long long`. -* **`REDIS_REPLY_NIL`**: +* **`VALKEY_REPLY_NIL`**: * The command replied with a **nil** object. There is no data to access. -* **`REDIS_REPLY_STRING`**: +* **`VALKEY_REPLY_STRING`**: * A bulk (string) reply. The value of the reply can be accessed using `reply->str`. The length of this string can be accessed using `reply->len`. -* **`REDIS_REPLY_ARRAY`**: +* **`VALKEY_REPLY_ARRAY`**: * A multi bulk reply. The number of elements in the multi bulk reply is stored in `reply->elements`. Every element in the multi bulk reply is a `valkeyReply` object as well and can be accessed via `reply->element[..index..]`. - Redis may reply with nested arrays but this is fully supported. + Valkey may reply with nested arrays but this is fully supported. ### RESP3 Libvalkey also supports every new `RESP3` data type which are as follows. For more information about the protocol see the `RESP3` [specification.](https://github.com/antirez/RESP3/blob/master/spec.md) -* **`REDIS_REPLY_DOUBLE`**: +* **`VALKEY_REPLY_DOUBLE`**: * The command replied with a double-precision floating point number. The value is stored as a string in the `str` member, and can be converted with `strtod` or similar. -* **`REDIS_REPLY_BOOL`**: +* **`VALKEY_REPLY_BOOL`**: * A boolean true/false reply. The value is stored in the `integer` member and will be either `0` or `1`. -* **`REDIS_REPLY_MAP`**: +* **`VALKEY_REPLY_MAP`**: * An array with the added invariant that there will always be an even number of elements. - The MAP is functionally equivalent to `REDIS_REPLY_ARRAY` except for the previously mentioned invariant. + The MAP is functionally equivalent to `VALKEY_REPLY_ARRAY` except for the previously mentioned invariant. -* **`REDIS_REPLY_SET`**: +* **`VALKEY_REPLY_SET`**: * An array response where each entry is unique. Like the MAP type, the data is identical to an array response except there are no duplicate values. -* **`REDIS_REPLY_PUSH`**: - * An array that can be generated spontaneously by Redis. +* **`VALKEY_REPLY_PUSH`**: + * An array that can be generated spontaneously by Valkey. This array response will always contain at least two subelements. The first contains the type of `PUSH` message (e.g. `message`, or `invalidate`), and the second being a sub-array with the `PUSH` payload itself. -* **`REDIS_REPLY_ATTR`**: +* **`VALKEY_REPLY_ATTR`**: * An array structurally identical to a `MAP` but intended as meta-data about a reply. - _As of Redis 6.0.6 this reply type is not used in Redis_ -* **`REDIS_REPLY_BIGNUM`**: +* **`VALKEY_REPLY_BIGNUM`**: * A string representing an arbitrarily large signed or unsigned integer value. The number will be encoded as a string in the `str` member of `valkeyReply`. -* **`REDIS_REPLY_VERB`**: +* **`VALKEY_REPLY_VERB`**: * A verbatim string, intended to be presented to the user without modification. The string payload is stored in the `str` member, and type data is stored in the `vtype` member (e.g. `txt` for raw text or `md` for markdown). @@ -230,9 +229,9 @@ Note that this function will take care of freeing sub-reply objects contained in arrays and nested arrays, so there is no need for the user to free the sub replies (it is actually harmful and will corrupt the memory). -**Important:** the current version of hiredis (1.0.0) frees replies when the +**Important:** the current version of valkey (1.0.0) frees replies when the asynchronous API is used. This means you should not call `freeReplyObject` when -you use this API. The reply is cleaned up by hiredis _after_ the callback +you use this API. The reply is cleaned up by libvalkey _after_ the callback returns. We may introduce a flag to make this configurable in future versions of the library. ### Cleaning up @@ -264,7 +263,7 @@ To explain how Libvalkey supports pipelining in a blocking connection, there nee understanding of the internal execution flow. When any of the functions in the `valkeyCommand` family is called, Libvalkey first formats the -command according to the Redis protocol. The formatted command is then put in the output buffer +command according to the Valkey protocol. The formatted command is then put in the output buffer of the context. This output buffer is dynamic, so it can hold any number of commands. After the command is put in the output buffer, `valkeyGetReply` is called. This function has the following two execution paths: @@ -285,7 +284,7 @@ void valkeyAppendCommand(valkeyContext *c, const char *format, ...); void valkeyAppendCommandArgv(valkeyContext *c, int argc, const char **argv, const size_t *argvlen); ``` After calling either function one or more times, `valkeyGetReply` can be used to receive the -subsequent replies. The return value for this function is either `REDIS_OK` or `REDIS_ERR`, where +subsequent replies. The return value for this function is either `VALKEY_OK` or `VALKEY_ERR`, where the latter means an error occurred while reading a reply. Just as with the other commands, the `err` field in the context can be used to find out what the cause of this error is. @@ -304,30 +303,30 @@ This API can also be used to implement a blocking subscriber: ```c reply = valkeyCommand(context,"SUBSCRIBE foo"); freeReplyObject(reply); -while(valkeyGetReply(context,(void *)&reply) == REDIS_OK) { +while(valkeyGetReply(context,(void *)&reply) == VALKEY_OK) { // consume message freeReplyObject(reply); } ``` ### Errors -When a function call is not successful, depending on the function either `NULL` or `REDIS_ERR` is +When a function call is not successful, depending on the function either `NULL` or `VALKEY_ERR` is returned. The `err` field inside the context will be non-zero and set to one of the following constants: -* **`REDIS_ERR_IO`**: +* **`VALKEY_ERR_IO`**: There was an I/O error while creating the connection, trying to write to the socket or read from the socket. If you included `errno.h` in your application, you can use the global `errno` variable to find out what is wrong. -* **`REDIS_ERR_EOF`**: +* **`VALKEY_ERR_EOF`**: The server closed the connection which resulted in an empty read. -* **`REDIS_ERR_PROTOCOL`**: +* **`VALKEY_ERR_PROTOCOL`**: There was an error while parsing the protocol. -* **`REDIS_ERR_OTHER`**: +* **`VALKEY_ERR_OTHER`**: Any other error. Currently, it is only used when a specified hostname to connect to cannot be resolved. @@ -343,7 +342,7 @@ and [libevent](http://monkey.org/~provos/libevent/). ### Connecting The function `valkeyAsyncConnect` can be used to establish a non-blocking connection to -Redis. It returns a pointer to the newly created `valkeyAsyncContext` struct. The `err` field +Valkey. It returns a pointer to the newly created `valkeyAsyncContext` struct. The `err` field should be checked after creation to see if there were errors creating the connection. Because the connection that will be created is non-blocking, the kernel is not able to instantly return if the specified host and port is able to accept a connection. @@ -383,21 +382,21 @@ have the following prototype: void(const valkeyAsyncContext *c, int status); ``` -On a *connect*, the `status` argument is set to `REDIS_OK` if the connection attempt succeeded. In this -case, the context is ready to accept commands. If it is called with `REDIS_ERR` then the +On a *connect*, the `status` argument is set to `VALKEY_OK` if the connection attempt succeeded. In this +case, the context is ready to accept commands. If it is called with `VALKEY_ERR` then the connection attempt failed. The `err` field in the context can be accessed to find out the cause of the error. After a failed connection attempt, the context object is automatically freed by the library after calling the connect callback. This may be a good point to create a new context and retry the connection. -On a disconnect, the `status` argument is set to `REDIS_OK` when disconnection was initiated by the -user, or `REDIS_ERR` when the disconnection was caused by an error. When it is `REDIS_ERR`, the `err` +On a disconnect, the `status` argument is set to `VALKEY_OK` when disconnection was initiated by the +user, or `VALKEY_ERR` when the disconnection was caused by an error. When it is `VALKEY_ERR`, the `err` field in the context can be accessed to find out the cause of the error. The context object is always freed after the disconnect callback fired. When a reconnect is needed, the disconnect callback is a good point to do so. Setting the connect or disconnect callbacks can only be done once per context. For subsequent calls the -api will return `REDIS_ERR`. The function to set the callbacks have the following prototype: +api will return `VALKEY_ERR`. The function to set the callbacks have the following prototype: ```c /* Alternatively you can use valkeyAsyncSetConnectCallbackNC which will be passed a non-const valkeyAsyncContext* on invocation (e.g. allowing writes to the privdata member). */ @@ -411,7 +410,7 @@ void appOnConnect(valkeyAsyncContext *c, int status) { myAppData *appData = (myAppData*)c->data; /* get my application specific context*/ appData->connecting = 0; - if (status == REDIS_OK) { + if (status == VALKEY_OK) { appData->connected = 1; } else { appData->connected = 0; @@ -427,7 +426,7 @@ void appOnDisconnect(valkeyAsyncContext *c, int status) appData->connected = 0; appData->err = c->err; appData->context = NULL; /* avoid stale pointer when callback returns */ - if (status == REDIS_OK) { + if (status == VALKEY_OK) { appNotifyDisconnectCompleted(mydata); } else { appNotifyUnexpectedDisconnect(mydata); @@ -440,7 +439,7 @@ void appOnDisconnect(valkeyAsyncContext *c, int status) In an asynchronous context, commands are automatically pipelined due to the nature of an event loop. Therefore, unlike the synchronous API, there is only a single way to send commands. -Because commands are sent to Redis asynchronously, issuing a command requires a callback function +Because commands are sent to Valkey asynchronously, issuing a command requires a callback function that is called when the reply is received. Reply callbacks should have the following prototype: ```c void(valkeyAsyncContext *c, void *reply, void *privdata); @@ -457,9 +456,9 @@ int valkeyAsyncCommandArgv( valkeyAsyncContext *ac, valkeyCallbackFn *fn, void *privdata, int argc, const char **argv, const size_t *argvlen); ``` -Both functions work like their blocking counterparts. The return value is `REDIS_OK` when the command -was successfully added to the output buffer and `REDIS_ERR` otherwise. Example: when the connection -is being disconnected per user-request, no new commands may be added to the output buffer and `REDIS_ERR` is +Both functions work like their blocking counterparts. The return value is `VALKEY_OK` when the command +was successfully added to the output buffer and `VALKEY_ERR` otherwise. Example: when the connection +is being disconnected per user-request, no new commands may be added to the output buffer and `VALKEY_ERR` is returned on calls to the `valkeyAsyncCommand` family. If the reply for a command with a `NULL` callback is read, it is immediately freed. When the callback @@ -486,14 +485,14 @@ When this function is called, the connection is **not** immediately terminated. commands are no longer accepted and the connection is only terminated when all pending commands have been written to the socket, their respective replies have been read and their respective callbacks have been executed. After this, the disconnection callback is executed with the -`REDIS_OK` status and the context object is freed. +`VALKEY_OK` status and the context object is freed. The connection can be forcefully disconnected using ```c void valkeyAsyncFree(valkeyAsyncContext *ac); ``` In this case, nothing more is written to the socket, all pending callbacks are called with a `NULL` -reply and the disconnection callback is called with `REDIS_OK`, after which the context object +reply and the disconnection callback is called with `VALKEY_OK`, after which the context object is freed. @@ -514,8 +513,8 @@ void valkeyReaderFree(valkeyReader *reader); int valkeyReaderFeed(valkeyReader *reader, const char *buf, size_t len); int valkeyReaderGetReply(valkeyReader *reader, void **reply); ``` -The same set of functions are used internally by hiredis when creating a -normal Redis context, the above API just exposes it to the user for a direct +The same set of functions are used internally by libvalkey when creating a +normal Valkey context, the above API just exposes it to the user for a direct usage. ### Usage @@ -528,7 +527,7 @@ buffer of the `valkeyReader` using `valkeyReaderFeed`. This function will make a copy of the buffer pointed to by `buf` for `len` bytes. This data is parsed when `valkeyReaderGetReply` is called. This function returns an integer status and a reply object (as described above) via `void **reply`. The returned status -can be either `REDIS_OK` or `REDIS_ERR`, where the latter means something went +can be either `VALKEY_OK` or `VALKEY_ERR`, where the latter means something went wrong (either a protocol error, or an out of memory error). The parser limits the level of nesting for multi bulk payloads to 7. If the @@ -538,7 +537,7 @@ multi bulk nesting level is higher than this, the parser returns an error. The function `valkeyReaderGetReply` creates `valkeyReply` and makes the function argument `reply` point to the created `valkeyReply` variable. For instance, if -the response of type `REDIS_REPLY_STATUS` then the `str` field of `valkeyReply` +the response of type `VALKEY_REPLY_STATUS` then the `str` field of `valkeyReply` will hold the status as a vanilla C string. However, the functions that are responsible for creating instances of the `valkeyReply` can be customized by setting the `fn` field on the `valkeyReader` struct. This should be done @@ -550,7 +549,7 @@ uses customized reply object functions to create Ruby objects. ### Reader max buffer Both when using the Reader API directly or when using it indirectly via a -normal Redis context, the valkeyReader structure uses a buffer in order to +normal Valkey context, the valkeyReader structure uses a buffer in order to accumulate data from the server. Usually this buffer is destroyed when it is empty and is larger than 16 KiB in order to avoid wasting memory in unused buffers @@ -561,18 +560,18 @@ an idle buffer changing the value of the `maxbuf` field of the reader structure to the desired value. The special value of 0 means that there is no maximum value for an idle buffer, so the buffer will never get freed. -For instance if you have a normal Redis context you can set the maximum idle +For instance if you have a normal Valkey context you can set the maximum idle buffer to zero (unlimited) just with: ```c context->reader->maxbuf = 0; ``` This should be done only in order to maximize performances when working with -large payloads. The context should be set back to `REDIS_READER_MAX_BUF` again +large payloads. The context should be set back to `VALKEY_READER_MAX_BUF` again as soon as possible in order to prevent allocation of useless memory. ### Reader max array elements -By default the hiredis reply parser sets the maximum number of multi-bulk elements +By default the libvalkey reply parser sets the maximum number of multi-bulk elements to 2^32 - 1 or 4,294,967,295 entries. If you need to process multi-bulk replies with more than this many elements you can set the value higher or to zero, meaning unlimited with: @@ -591,7 +590,7 @@ SSL/TLS support is not built by default and requires an explicit flag: This requires OpenSSL development package (e.g. including header files to be available. -When enabled, SSL/TLS support is built into extra `libhiredis_ssl.a` and +When enabled, SSL/TLS support is built into extra `libvalkey_ssl.a` and `libhiredis_ssl.so` static/dynamic libraries. This leaves the original libraries unaffected so no additional dependencies are introduced. @@ -604,8 +603,8 @@ First, you'll need to make sure you include the SSL header file: #include ``` -You will also need to link against `libhiredis_ssl`, **in addition** to -`libhiredis` and add `-lssl -lcrypto` to satisfy its dependencies. +You will also need to link against `libhivalkey_ssl`, **in addition** to +`libvalkey` and add `-lssl -lcrypto` to satisfy its dependencies. Libvalkey implements SSL/TLS on top of its normal `valkeyContext` or `valkeyAsyncContext`, so you will need to establish a connection first and then @@ -632,7 +631,7 @@ valkeySSLContext *ssl_context; /* An error variable to indicate what went wrong, if the context fails to * initialize. */ -valkeySSLContextError ssl_error = REDIS_SSL_CTX_NONE; +valkeySSLContextError ssl_error = VALKEY_SSL_CTX_NONE; /* Initialize global OpenSSL state. * @@ -647,27 +646,27 @@ ssl_context = valkeyCreateSSLContext( "/path/to/certs", /* Path of trusted certificates, optional */ "client_cert.pem", /* File name of client certificate file, optional */ "client_key.pem", /* File name of client private key, optional */ - "redis.mydomain.com", /* Server name to request (SNI), optional */ + "valkey.mydomain.com", /* Server name to request (SNI), optional */ &ssl_error); -if(ssl_context == NULL || ssl_error != REDIS_SSL_CTX_NONE) { +if(ssl_context == NULL || ssl_error != VALKEY_SSL_CTX_NONE) { /* Handle error and abort... */ /* e.g. printf("SSL error: %s\n", - (ssl_error != REDIS_SSL_CTX_NONE) ? + (ssl_error != VALKEY_SSL_CTX_NONE) ? valkeySSLContextGetError(ssl_error) : "Unknown error"); // Abort */ } -/* Create Redis context and establish connection */ +/* Create Valkey context and establish connection */ c = valkeyConnect("localhost", 6443); if (c == NULL || c->err) { /* Handle error and abort... */ } /* Negotiate SSL/TLS */ -if (valkeyInitiateSSLWithContext(c, ssl_context) != REDIS_OK) { +if (valkeyInitiateSSLWithContext(c, ssl_context) != VALKEY_OK) { /* Handle error, in c->err / c->errstr */ } ``` @@ -698,7 +697,7 @@ void my_push_handler(void *privdata, void *reply) { void my_async_push_handler(valkeyAsyncContext *ac, void *reply) { /* Handle the reply */ - /* Note: Because async hiredis always frees replies, you should + /* Note: Because async libvalkey always frees replies, you should not call freeReplyObject in an async push callback. */ } ``` @@ -709,7 +708,7 @@ There are two ways to set your own PUSH handlers. 1. Set `push_cb` or `async_push_cb` in the `valkeyOptions` struct and connect with `valkeyConnectWithOptions` or `valkeyAsyncConnectWithOptions`. ```c valkeyOptions = {0}; - REDIS_OPTIONS_SET_TCP(&options, "127.0.0.1", 6379); + VALKEY_OPTIONS_SET_TCP(&options, "127.0.0.1", 6379); options->push_cb = my_push_handler; valkeyContext *context = valkeyConnectWithOptions(&options); ``` @@ -722,12 +721,12 @@ There are two ways to set your own PUSH handlers. _Note `valkeySetPushCallback` and `valkeyAsyncSetPushCallback` both return any currently configured handler, making it easy to override and then return to the old value._ ### Specifying no handler -If you have a unique use-case where you don't want hiredis to automatically intercept and free PUSH replies, you will want to configure no handler at all. This can be done in two ways. -1. Set the `REDIS_OPT_NO_PUSH_AUTOFREE` flag in `valkeyOptions` and leave the callback function pointer `NULL`. +If you have a unique use-case where you don't want libvalkey to automatically intercept and free PUSH replies, you will want to configure no handler at all. This can be done in two ways. +1. Set the `VALKEY_OPT_NO_PUSH_AUTOFREE` flag in `valkeyOptions` and leave the callback function pointer `NULL`. ```c valkeyOptions = {0}; - REDIS_OPTIONS_SET_TCP(&options, "127.0.0.1", 6379); - options->options |= REDIS_OPT_NO_PUSH_AUTOFREE; + VALKEY_OPTIONS_SET_TCP(&options, "127.0.0.1", 6379); + options->options |= VALKEY_OPT_NO_PUSH_AUTOFREE; valkeyContext *context = valkeyConnectWithOptions(&options); ``` 3. Call `valkeySetPushCallback` with `NULL` once connected. diff --git a/libvalkey/test.c b/libvalkey/test.c index 10b6e295..7b23a445 100644 --- a/libvalkey/test.c +++ b/libvalkey/test.c @@ -112,7 +112,7 @@ static long long usec(void) { } while (1) /* Helper to extract Redis version information. Aborts on any failure. */ -#define VALKEY_VERSION_FIELD "valkey_version:" +#define VALKEY_VERSION_FIELD "redis_version:" void get_valkey_version(valkeyContext *c, int *majorptr, int *minorptr) { valkeyReply *reply; char *eptr, *s, *e;