Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
别团等shy哥发育
redis
提交
1a06bbe4
R
redis
项目概览
别团等shy哥发育
/
redis
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
redis
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
1a06bbe4
编写于
10月 25, 2013
作者:
A
antirez
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Fixed typos in dictScan() comment.
上级
0880bec4
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
2 addition
and
2 deletion
+2
-2
src/dict.c
src/dict.c
+2
-2
未找到文件。
src/dict.c
浏览文件 @
1a06bbe4
...
...
@@ -698,7 +698,7 @@ static unsigned long rev(unsigned long v) {
* (in binary) 1111. The position of a key in the hash table will be always
* the last four bits of the hash output, and so forth.
*
* WHAT HAPPENS
DURING REHASHING, WHEN YOU HAVE TWO TABLES
?
* WHAT HAPPENS
IF THE TABLE CHANGES IN SIZE
?
*
* If the hash table grows, elements can go anyway in one multiple of
* the old bucket: for example let's say that we already iterated with
...
...
@@ -720,7 +720,7 @@ static unsigned long rev(unsigned long v) {
* as we are sure that, we tried for example, both 0111 and 1111 (all the
* variations of the higher bit) so we don't need to test it again.
*
*
But wait... You have *two* tables in a given moment during rehashing
!
*
WAIT... YOU HAVE *TWO* TABLES DURING REHASHING
!
*
* Yes, this is true, but we always iterate the smaller one of the tables,
* testing also all the expansions of the current cursor into the larger
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录