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

有几个问题想咨询一下 #95

Open
liuxw7 opened this issue Mar 31, 2023 · 3 comments
Open

有几个问题想咨询一下 #95

liuxw7 opened this issue Mar 31, 2023 · 3 comments

Comments

@liuxw7
Copy link

liuxw7 commented Mar 31, 2023

1、发送端在发送消息的时候,如何知道有有哪几个客户端,退出了连接,是怎么实现的。
2、对于高频的发送是否支持,比如发送周期是10ms一次的,循环发送。这样会不会导致内存泄露。
3、在高频(20m<)发送的情况下,send出去之后,假如有10个recv,会不会有抢不到资源的recv。
4、在高频情况下,cpu使用率是不是会上升很快,甚至导致其他程序得不到资源。

谢谢mutouyun。

@mutouyun
Copy link
Owner

mutouyun commented Apr 2, 2023

1、发送端在发送消息的时候,如何知道有有哪几个客户端,退出了连接,是怎么实现的。
》channel会创建一个计数器

2、对于高频的发送是否支持,比如发送周期是10ms一次的,循环发送。这样会不会导致内存泄露。
》10ms频率不是很高。只要你接收端处理足够及时,没问题

3、在高频(20m<)发送的情况下,send出去之后,假如有10个recv,会不会有抢不到资源的recv。
》广播 broadcast 模式下不会有 recv 收不到消息,除非某个 recv 处理不及时,导致发送方等待超时

4、在高频情况下,cpu使用率是不是会上升很快,甚至导致其他程序得不到资源。
》正常情况下不会。但确实之前有解决一些意外的导致 cpu 升高的 bug。
》目前的版本对程序退出不友好(因为我之前写这个库的时候,使用场景是嵌入式环境,进程不会重启,coredump只会重启系统),所以要注意你是不是有需要正常退出后再启动的情况。

@liuxw7
Copy link
Author

liuxw7 commented Apr 3, 2023

是不是说,对于异常退出的进程,计数器无法改变其计数,这样就会导致内存泄露。

@mutouyun
Copy link
Owner

mutouyun commented Apr 5, 2023

其实倒不是内存泄漏,计数器无法改变会导致发送端长时间等待接收端。
目前的做法是超时会自动清理一次连接标记。
但由于清理动作本身不是无锁的(其实是没考虑清理的同时出现新的接收端),异常退出再启动很容易出问题。

另外还有一些对异常退出很不友好的 bug,参看:#79 #88

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