We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
1、发送端在发送消息的时候,如何知道有有哪几个客户端,退出了连接,是怎么实现的。 2、对于高频的发送是否支持,比如发送周期是10ms一次的,循环发送。这样会不会导致内存泄露。 3、在高频(20m<)发送的情况下,send出去之后,假如有10个recv,会不会有抢不到资源的recv。 4、在高频情况下,cpu使用率是不是会上升很快,甚至导致其他程序得不到资源。
谢谢mutouyun。
The text was updated successfully, but these errors were encountered:
1、发送端在发送消息的时候,如何知道有有哪几个客户端,退出了连接,是怎么实现的。 》channel会创建一个计数器
2、对于高频的发送是否支持,比如发送周期是10ms一次的,循环发送。这样会不会导致内存泄露。 》10ms频率不是很高。只要你接收端处理足够及时,没问题
3、在高频(20m<)发送的情况下,send出去之后,假如有10个recv,会不会有抢不到资源的recv。 》广播 broadcast 模式下不会有 recv 收不到消息,除非某个 recv 处理不及时,导致发送方等待超时
4、在高频情况下,cpu使用率是不是会上升很快,甚至导致其他程序得不到资源。 》正常情况下不会。但确实之前有解决一些意外的导致 cpu 升高的 bug。 》目前的版本对程序退出不友好(因为我之前写这个库的时候,使用场景是嵌入式环境,进程不会重启,coredump只会重启系统),所以要注意你是不是有需要正常退出后再启动的情况。
Sorry, something went wrong.
是不是说,对于异常退出的进程,计数器无法改变其计数,这样就会导致内存泄露。
其实倒不是内存泄漏,计数器无法改变会导致发送端长时间等待接收端。 目前的做法是超时会自动清理一次连接标记。 但由于清理动作本身不是无锁的(其实是没考虑清理的同时出现新的接收端),异常退出再启动很容易出问题。
另外还有一些对异常退出很不友好的 bug,参看:#79 #88
No branches or pull requests
1、发送端在发送消息的时候,如何知道有有哪几个客户端,退出了连接,是怎么实现的。
2、对于高频的发送是否支持,比如发送周期是10ms一次的,循环发送。这样会不会导致内存泄露。
3、在高频(20m<)发送的情况下,send出去之后,假如有10个recv,会不会有抢不到资源的recv。
4、在高频情况下,cpu使用率是不是会上升很快,甚至导致其他程序得不到资源。
谢谢mutouyun。
The text was updated successfully, but these errors were encountered: