cpp-ipc
cpp-ipc copied to clipboard
mutouyun
怎样清空之前的接收进程?
当之前的接收进展不正常退出时, 此时对应的接收进程没有正常退出, 相应的que__的recv_conn次数也不会下降, 以至达到最大数量32... 有没有方便的接口可以快速清楚之前生成的所有接收进程?
确实如你所说，因为我仅用了共享内存，进程崩溃对端是无感知的。 我一般是在signal中捕获异常情况，然后显式调用disconnect来执行清理动作。
其实我在遇到发送超时的时候，有设计清除无效（引起超时的）连接标记的机制。 当环形队列满了，仍然有数据（接收者）未完成消费，就会触发超时等待（默认100ms）。
默认环形队列255，所以我有点奇怪。。除非系统在消息通讯写满队列的这段时间里，出现二三十次接收者崩溃，否则不会出现你的这个情况。。
这里环形队列的长度255是指发送内容的长度255吗? 这样是否意味着我一直发送超过255的内容, 环形队列就会一直处于满的状态?
在这个过程中如果遇到段错误之类的强制退出, 有概率无法触发异常signal, 接收就会直接崩溃, 然后多次调试后确实会达到最大数量.
暂时没有，我考虑加一个吧。
其实我以前的版本有这种接口，但后来我把它删掉了。 主要是粗暴的清空所有连接，有可能会导致其他问题，在这个接口的使用上必须小心，确保没有其他进程在用这个消息通道。
在同一name使用传输多次后, 发送端会有几率触发以下问题:
prod_cons.h, 242: ipc::log("force_push: k = %u, cc = %u, rem_cc = %u\n", k, cc, cur_rc);
prod_cons.h, 243: cc = wrapper->elems()->disconnect(cur_rc); // disconnect all remained readers
prod_cons.h, 244: if (cc == 0) return false; // no reader
每100ms传输一次, 每次传输的数据2MB左右. 我感觉依然是之前的receiver进程没有退出干净导致的, 但是recv_conn的数量是正常的.
在同一name使用传输多次后, 发送端会有几率触发以下问题:
prod_cons.h, 242: ipc::log("force_push: k = %u, cc = %u, rem_cc = %u\n", k, cc, cur_rc); prod_cons.h, 243: cc = wrapper->elems()->disconnect(cur_rc); // disconnect all remained readers prod_cons.h, 244: if (cc == 0) return false; // no reader每100ms传输一次, 每次传输的数据2MB左右. 我感觉依然是之前的receiver进程没有退出干净导致的, 但是recv_conn的数量是正常的.
走到这里，说明有receiver意外退出，消息队列满了有消息还没消费完。 这里是自动清理超时连接的逻辑，因此这段代码走过之后，recv_conn的数量就正常了。
这个disconnect也会随之清理消息队列对吧?
所以得到这个false之后我不应该立即关闭发送端退出程序, 而是应该直接尝试重新发送数据?
对的，你看下还存活的接收端是不是收到数据了。这个提示不影响正常的接收端。
Sender端2MB数据每20ms发送一次的话, Receiver的recv()函数会等待超过50ms, 甚至在一些情况下超过100ms, 这是什么原因导致的呢?
我调整了ipc::data_length, 发现并没有明显的改善...
Sender端2MB数据每20ms发送一次的话, Receiver的recv()函数会等待超过50ms, 甚至在一些情况下超过100ms, 这是什么原因导致的呢?
我调整了ipc::data_length, 发现并没有明显的改善...
发送接收是单对单的, "ssu"