-
Notifications
You must be signed in to change notification settings - Fork 24.5k
Description
Hello. This is a feature request / documentation bug report.
The documentation page for BLPOP says:
The timeout argument is interpreted as an integer value specifying the maximum number of seconds to block.
In reality, BLPOP blocks for a time between timeout and (timeout + 1), giving up on blocking when system UNIX timestamp changes (which has a second precision)
So the feature request is: make BLPOP and other blocking routines follow the exact timeout specified
As I can see, it can be done easily with minimal changes:
- clientsCron() already gets called REDIS_HZ times per second
- Use floating-point type instead of time_t for blockingState::timeout
- Use floating-point for redisServer::unixtime also
- Set redisServer::unixtime with clock_gettime() or smth instead of time(NULL)
or smth like that.
The old behavior is really annoying if you think of a situation where many clients (1000+) constantly and simultaneously block on different keys with short timeouts (say, 2 sec). This situation is very common in environments with users sending each other messages.
With the current implementation, Redis shall give up on blocking when system time changes, and cause high server load every second, preventing an even distribution of server load.
Would appreciate if it gets implemented, this could save tons of pain in the ass.