Minor improvements to module blocked on keys #7903
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix redis#7879 redis#7880 1. Fix some comments 2. Make sure blocked-on-keys client privdata is accessible from withing the timeout callback 3. Handle blocked clients in beforeSleep - In case a key becomses "ready" outside of processCommand
oranagra
approved these changes
Oct 12, 2020
oranagra
changed the title
oranagra
pushed a commit
to oranagra/redis
that referenced
this pull request
Oct 26, 2020
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880 (cherry picked from commit addf47d)
Merged
oranagra
pushed a commit
to oranagra/redis
that referenced
this pull request
Oct 26, 2020
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880 (cherry picked from commit addf47d)
JackieXie168
pushed a commit
to JackieXie168/redis
that referenced
this pull request
Nov 4, 2020
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880
jschmieg
pushed a commit
to memKeyDB/memKeyDB
that referenced
this pull request
Nov 6, 2020
- Clarify some documentation comments - Make sure blocked-on-keys client privdata is accessible from withing the timeout callback - Handle blocked clients in beforeSleep - In case a key becomes "ready" outside of processCommand See redis#7879 redis#7880 (cherry picked from commit addf47d)
oranagra
added a commit
to oranagra/redis
that referenced
this pull request
Nov 17, 2020
This is hopefully usually harmles. The server.ready_keys will usually be empty so the code after releasing the GIL will soon be done. The only case where it'll actually process things is when a module releases a client (or module) blocked on a key, by triggering this NOT from within a command (e.g. a timer event). This bug was introduced in redis 6.0.9, see redis#7903
oranagra
added a commit
that referenced
this pull request
Nov 22, 2020
This is hopefully usually harmles. The server.ready_keys will usually be empty so the code after releasing the GIL will soon be done. The only case where it'll actually process things is when a module releases a client (or module) blocked on a key, by triggering this NOT from within a command (e.g. a timer event). This bug was introduced in redis 6.0.9, see #7903
oranagra
added a commit
to oranagra/redis
that referenced
this pull request
Jan 11, 2021
This is hopefully usually harmles. The server.ready_keys will usually be empty so the code after releasing the GIL will soon be done. The only case where it'll actually process things is when a module releases a client (or module) blocked on a key, by triggering this NOT from within a command (e.g. a timer event). This bug was introduced in redis 6.0.9, see redis#7903 (cherry picked from commit e6fa473)
oranagra
added a commit
that referenced
this pull request
Jan 12, 2021
This is hopefully usually harmles. The server.ready_keys will usually be empty so the code after releasing the GIL will soon be done. The only case where it'll actually process things is when a module releases a client (or module) blocked on a key, by triggering this NOT from within a command (e.g. a timer event). This bug was introduced in redis 6.0.9, see #7903 (cherry picked from commit e6fa473)
JackieXie168
pushed a commit
to JackieXie168/redis
that referenced
this pull request
Mar 2, 2021
This is hopefully usually harmles. The server.ready_keys will usually be empty so the code after releasing the GIL will soon be done. The only case where it'll actually process things is when a module releases a client (or module) blocked on a key, by triggering this NOT from within a command (e.g. a timer event). This bug was introduced in redis 6.0.9, see redis#7903
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #7879 #7880
from withing the timeout callback
becomses "ready" outside of processCommand