sender和receiver的异常退出处理机制
Peachck opened this issue · 15 comments
与issue #100 存在的问题类似，在将使用sender和receiver的进程强制关闭后，再次唤起进程，会出现共享内存的乱码与报错，请问如果想解决该问题，应该从哪些文件下手进行修改优化？感谢
其实简单场景里是好办的。比如崩溃时重启所有ipc中的进程（也就是重启系统），我之前的使用场景主要是这种情况（车载IVI嵌入式环境）。如果不是卡死而是乱码就有点奇怪了，看起来像是bug，我这周末估计没空，得等8月中旬，找个周末我反复测试下看看。
如果不能简单重启怎么办？没办法调用disconnect，特别是存在kill -9 无法捕获的信号，不要求异常期间缓存数据，有什么好的解决办法吗？感谢感谢！
好的感谢，具体来说，在一个类似单Reactor多进程的应用场景下，每一个进程中都存在一个sender和一个receiver，对于这个应用场景下的多次强制关闭进程会导致该进程无法正确获取共享内存中的数据，并且有概率输出乱码，也有卡死的情况出现
我注意到send函数中存在ipc::log("fouce_push: msg_id = %zd, remain = %d, size = %zd\n")的强制推送日志输出，在上述问题发生的时候log打印信息为force_push : msg_id = 3208, remain = 2231384, size = 64,希望这个输出对错误定位有帮助
其实简单场景里是好办的。比如崩溃时重启所有ipc中的进程（也就是重启系统），我之前的使用场景主要是这种情况（车载IVI嵌入式环境）。如果不是卡死而是乱码就有点奇怪了，看起来像是bug，我这周末估计没空，得等8月中旬，找个周末我反复测试下看看。
请问您是成功disconnect了que_，实现了channel的缓存清理吗？
…
---- 回复的原邮件 ---- | 发件人 | @.> | | 发送日期 | 2024年08月02日 16:15 | | 收件人 | mutouyun/cpp-ipc @.> | | 抄送人 | Pekiwe @.>, Author @.> | | 主题 | Re: [mutouyun/cpp-ipc] sender和receiver的异常退出处理机制 (Issue #123) | 如果不能简单重启怎么办？没办法调用disconnect，特别是存在kill -9 无法捕获的信号，不要求异常期间缓存数据，有什么好的解决办法吗？感谢感谢！ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
没有，kill -9 没办法捕获去disconnect，清楚缓存需要确保进程都退出了，这个也办法保证
确认一下，你们的场景用的是broadcast吗？如果是的话，能允许丢消息吗？
确认一下，你们的场景用的是broadcast吗？如果是的话，能允许丢消息吗？
用的是broadcast；目前处理的是视频帧，可以接受丢消息，最优情况是去丢较旧的消息
现在正在尝试使用issue37提到的方法，在更上层解决这个问题，具体来说利用上层已经有的进程监控，每当新的进程被拉起的时候建立一条新的channel用来传输数据
broadcast模式下的质量保证太强了，所以才必须要求连接。只要broadcast允许丢消息，其实连接就无所谓了。如果弱化了连接的概念，异常退出就可以随时连上了。我计划这两周改一个大版本，降低broadcast的质量保证，看下一般情况下还有没有异常退出的问题。
确认一下，你们的场景用的是broadcast吗？如果是的话，能允许丢消息吗？
我模仿的是c-s的模式，client-server的一条链接代表一条session,每个session有两个unicast_channel，不需要broadcast
using unicast_channel = chan<relat::single, relat::single, trans::unicast>;
std::shared_ptripc::unicast_channel ipc_r_ptr_;
std::shared_ptripc::unicast_channel ipc_w_ptr_;
我这个需要怎么修改呢？
点对点通讯应该不依赖连接才对，你的两条点到点的unicast_channel，也有崩溃重启无法恢复的问题吗？
点对点通讯应该不依赖连接才对，你的两条点到点的unicast_channel，也有崩溃重启无法恢复的问题吗？
是的，重启后会不停打印“fail: send, que->ready_sending() == false”这个错误
broadcast模式下的质量保证太强了，所以才必须要求连接。只要broadcast允许丢消息，其实连接就无所谓了。如果弱化了连接的概念，异常退出就可以随时连上了。我计划这两周改一个大版本，降低broadcast的质量保证，看下一般情况下还有没有异常退出的问题。
现在先用修改data_length，default_timeout，large_msg_cache以及增加上层握手机制来暂缓了这个问题😂权宜之计了一下
感觉这个连接的设计太让人痛苦了。我想想有什么办法可以完全无连接。。
各位，最近公司太卷了，每天下班都这个点了。。估计要折腾到十一，之后我应该能腾出时间继续搞开源库……
各位，最近公司太卷了，每天下班都这个点了。。估计要折腾到十一，之后我应该能腾出时间继续搞开源库……
好的，我应该9月份之后有时间进行研究修改，到时候遇到问题继续跟您沟通联系😀