Modules: block on keys: fix the top comments.
This commit is contained in:
parent
91f4bdc9f9
commit
629081f839
41
src/module.c
41
src/module.c
@ -4119,36 +4119,41 @@ RedisModuleBlockedClient *RM_BlockClient(RedisModuleCtx *ctx, RedisModuleCmdFunc
|
|||||||
* Anyway we can't be sure if the client should be unblocked just because the
|
* Anyway we can't be sure if the client should be unblocked just because the
|
||||||
* key is signaled as ready: for instance a successive operation may change the
|
* key is signaled as ready: for instance a successive operation may change the
|
||||||
* key, or a client in queue before this one can be served, modifying the key
|
* key, or a client in queue before this one can be served, modifying the key
|
||||||
* as well and making it empty again. So when blocking for keys, we need to
|
* as well and making it empty again. So when a client is blocked with
|
||||||
* register a callback called is_key_ready. This callback gets called with
|
* RedisModule_BlockClientOnKeys() the reply callback is not called after
|
||||||
* a context, selected with the right database, and the key name: if it
|
* RM_UnblockCLient() is called, but every time a key is signaled as ready:
|
||||||
* returns 1, then we proceed calling the reply callback, otherwise if the
|
* if the reply callback can serve the client, it returns REDISMODULE_OK
|
||||||
* is_key_ready callback returns 0 the client is not unblocked, since the
|
* and the client is unblocked, otherwise it will return REDISMODULE_ERR
|
||||||
* key is yet not ready.
|
* and we'll try again later.
|
||||||
|
*
|
||||||
|
* The reply callback can access the key that was signaled as ready by
|
||||||
|
* calling the API RedisModule_GetBlockedClientReadyKey(), that returns
|
||||||
|
* just the string name of the key as a RedisModuleString object.
|
||||||
*
|
*
|
||||||
* Thanks to this system we can setup complex blocking scenarios, like
|
* Thanks to this system we can setup complex blocking scenarios, like
|
||||||
* unblocking a client only if a list contains at least 5 items or other
|
* unblocking a client only if a list contains at least 5 items or other
|
||||||
* more fancy logics.
|
* more fancy logics.
|
||||||
*
|
*
|
||||||
* Note that another difference with RedisModule_BlockClient(), is that here
|
* Note that another difference with RedisModule_BlockClient(), is that here
|
||||||
* we pass the private data directly when blocking the client: such private
|
* we pass the private data directly when blocking the client: it will
|
||||||
* data will be later provided both to the is_key_ready callback, and to the
|
* be accessible later in the reply callback. Normally when blocking with
|
||||||
* reply callback. Normally in RedisModule_BlockClient() the private data
|
* RedisModule_BlockClient() the private data to reply to the client is
|
||||||
* to reply to the client is passed when calling RedisModule_UnblockClient()
|
* passed when calling RedisModule_UnblockClient() but here the unblocking
|
||||||
* but here the unblocking is performed by Redis itself, so we need to have
|
* is performed by Redis itself, so we need to have some private data before
|
||||||
* some private data before hand. The private data is used to store any
|
* hand. The private data is used to store any information about the specific
|
||||||
* information about the specific unblocking operation that you are
|
* unblocking operation that you are implementing. Such information will be
|
||||||
* implementing. Such information will be freed using the free_privdata
|
* freed using the free_privdata callback provided by the user.
|
||||||
* callback provided by the user. */
|
*
|
||||||
|
* However the reply callback will be able to access the argument vector of
|
||||||
|
* the command, so the private data is often not needed. */
|
||||||
RedisModuleBlockedClient *RM_BlockClientOnKeys(RedisModuleCtx *ctx, RedisModuleCmdFunc reply_callback, RedisModuleCmdFunc timeout_callback, void (*free_privdata)(RedisModuleCtx*,void*), long long timeout_ms, RedisModuleString **keys, int numkeys, void *privdata) {
|
RedisModuleBlockedClient *RM_BlockClientOnKeys(RedisModuleCtx *ctx, RedisModuleCmdFunc reply_callback, RedisModuleCmdFunc timeout_callback, void (*free_privdata)(RedisModuleCtx*,void*), long long timeout_ms, RedisModuleString **keys, int numkeys, void *privdata) {
|
||||||
return moduleBlockClient(ctx,reply_callback,timeout_callback,free_privdata,timeout_ms, keys,numkeys,privdata);
|
return moduleBlockClient(ctx,reply_callback,timeout_callback,free_privdata,timeout_ms, keys,numkeys,privdata);
|
||||||
}
|
}
|
||||||
|
|
||||||
/* This function is used in order to potentially unblock a client blocked
|
/* This function is used in order to potentially unblock a client blocked
|
||||||
* on keys with RedisModule_BlockClientOnKeys(). When this function is called,
|
* on keys with RedisModule_BlockClientOnKeys(). When this function is called,
|
||||||
* all the clients blocked for this key will get their is_key_ready callback,
|
* all the clients blocked for this key will get their reply callback called,
|
||||||
* and if the callback returns non-zero the client will be unblocked and the
|
* and if the callback returns REDISMODULE_OK the client will be unblocked. */
|
||||||
* reply callback will be called in order to reply to the client. */
|
|
||||||
void RM_SignalKeyAsReady(RedisModuleCtx *ctx, RedisModuleString *key) {
|
void RM_SignalKeyAsReady(RedisModuleCtx *ctx, RedisModuleString *key) {
|
||||||
signalKeyAsReady(ctx->client->db, key);
|
signalKeyAsReady(ctx->client->db, key);
|
||||||
}
|
}
|
||||||
|
Loading…
x
Reference in New Issue
Block a user