upstream/redis
1
0
Fork 0
mirror of https://github.com/redis/redis.git synced 2026-06-03 22:01:02 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 19

Clarify HNSW_MAX_THREADS vs one thread per request.

Browse source
This commit is contained in:
antirez 2025-03-20 15:42:11 +01:00
parent 758e963a4e
commit f330d6175a
1 changed files with 8 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
vset.c
View file

@ -881,7 +881,14 @@ int VSIM_RedisCommand(RedisModuleCtx *ctx, RedisModuleString **argv, int argc) {
* 2. If the write lock is taken while destroying the object, another
* command or operation (expire?) from the main thread acquired
* it to delete the object, so *it* will block if there are still
* operations in progress on this key. */
* operations in progress on this key.
*
* Note: even if we create one thread per request, the underlying
* HNSW library has a fixed number of slots for the threads, as it's
* defined in HNSW_MAX_THREADS (beware that if you increase it,
* every node will use more memory). This means that while this request
* is threaded, and will NOT block Redis, it may end waiting for a
* free slot if all the HNSW_MAX_THREADS slots are used. */
pthread_rwlock_rdlock(&vset->in_use_lock);
RedisModuleBlockedClient *bc = RedisModule_BlockClient(ctx,NULL,NULL,NULL,0);