Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use unlimited list instead slice of array #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cofyc
Copy link

@cofyc cofyc commented Jul 21, 2015

tv[i] = append(tv[i], t)
t.vec = tv[i]
t.index = len(tv[i]) - 1

以前默认创建的 128 大小的 []_timer 数组,如果超过 128 大小后,append 内部会生成新的 []_timer 数组,导致之前 _timer 引用的 []_timer 中 index 位置不一定为正确的 *timer 。

我这是使用 container.list.List 对象来实现同样功能,不会因为里面对象的变更导致对列表的引用失效。

暂未做很严格以及性能测试,但前面描述的 bug 是很明确的。在我做压力测试因为会一瞬间建立比较多连接,就暴露出来了。

@cofyc cofyc changed the title Use unlimit list instead slice of array Use unlimited list instead slice of array Jul 21, 2015
@siddontang
Copy link
Owner

多谢,应该是这句导致的

tv[i] = append(tv[i], t)

那如果是这样,我觉得可以在append的时候判断是不是capability不够了需要扩容,如果扩容了,可以干的事情是先重新分配一个两倍的slice,然后将原先的东西copy过去,在重新append,这样应该数据就是正确地了。

不过我现在还没测试,不知道是否可行。

@wllenyj
Copy link

wllenyj commented May 29, 2018

index拿出不正确的timer不是因为append。
是因为#12 有数据竞争,
w.tv1[index] = vec[0:0:defaultTimerSize]以后再
tv[i] = append(tv[i], t)

for _, t := range vec {
引用的是相同底层数据,但for语句又没有上锁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants