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

优化/修复项建议 #20

Open
cokeboL opened this issue Jul 19, 2019 · 5 comments
Open

优化/修复项建议 #20

cokeboL opened this issue Jul 19, 2019 · 5 comments

Comments

@cokeboL
Copy link

cokeboL commented Jul 19, 2019

  1. znet/server.go

此处go了一个新协程是可以省略的,dealConn.Start() 中又go了读写两个协程就可以了,如果怕CallOnConnStart有慢操作影响accept速度,可以把CallOnConnStart移到读协程中去执行

go dealConn.Start()
@cokeboL
Copy link
Author

cokeboL commented Jul 19, 2019

  1. Connection的Stop没有保证一致性,比如应用层主动调用Stop,读协程中刚好触发了Stop,两个协程在判断 c.isClosed 时都是false,后面的close chan等就会执行多次,导致panic,此处可以改成原子或者加锁

@cokeboL
Copy link
Author

cokeboL commented Jul 19, 2019

  1. func (c *Connection) StartWriter() 中最好也defer Stop, 比如客户端关闭了读,会触发写失败,写协程已经退出了,但是客户端读并没有失败,不能及时关闭异常连接,应用层可能继续给这个Connection发包,然后请看问题4

@cokeboL
Copy link
Author

cokeboL commented Jul 19, 2019

  1. Connection的SendMsg中,建议用select + default,避免chan满时导致应用层阻塞
c.msgChan <- msg //chan满时导致阻塞,比如3中的场景,应用层持续给这个连接SendMsg,满了,然后阻塞了,如果应用层是广播的逻辑后者任务池中发的这个包,其他模块就都被阻塞了,直到此连接其他情况退出时才恢复

@cokeboL
Copy link
Author

cokeboL commented Jul 19, 2019

只看了几分钟代码,暂时感觉以上几个地方存在问题,如果有讲的不准确的地方咱们再讨论,作者大佬看下是否需要优化、修复

@cokeboL cokeboL changed the title 优化建议 优化/修复建议 Jul 19, 2019
@cokeboL cokeboL changed the title 优化/修复建议 优化/修复项建议 Jul 19, 2019
@aceld
Copy link
Owner

aceld commented Jul 20, 2019

非常感谢您的建议,我们会斟酌您的建议 修正之后合并到代码之中,如果您也想直接修复的话,也可以直接提交 Pull Request哈。

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

No branches or pull requests

2 participants