木头云

这是因为接收方来不及收取消息，会造成消息堆积。 目前消息队列总长度为255，超出长度，又过了100ms超时仍然堆积的情况，sender会通过force_push强行写入。 force_push强行写入会清理导致超时的receiver（因为可能意外崩溃或卡死，不能无限制的每次都等待），因此对接收来不及的receiver来说，相当于被踢了。 你的例子里，receiver并没有死，而是人为制造了100ms等待，因此receiver被踢了以后就无限等在那了。 你这个情况我后面考虑加个机制，当receiver被踢掉以后自己需要知道，这样recv就会直接退出了。

> 而接收端还需要处理数据，速度就跟不上。 这是不行的，这样必然会导致消息丢失。 正确的做法是，你需要自己做一层隔离，接收消息应该放到你自己的内存队列里做cache，处理的时候从cache中取。 > 等待接端接收到数据之后，发送函数再返回 > 每次发送的时候获取一下消息队列的状态，队列满的时候发送方阻塞等待一下 如上这种逻辑，不是ipc通讯组件需要考虑的，需要的是类似 **rpc** 的逻辑。 你需要基于ipc自己实现一套，或者直接使用现成的rpc框架，比如： https://github.com/alephzero/alephzero https://github.com/eclipse-iceoryx/iceoryx https://github.com/qicosmos/rest_rpc > 另外有一个问题，开源库支持多发多收、单发多收，但是没有找到单发单收功能 参见：https://github.com/mutouyun/cpp-ipc/wiki/Tutorial#%E8%87%AA%E5%AE%9A%E4%B9%89%E5%8A%9F%E8%83%BD

发送端在堵塞的时候其实是有等待的，你可以在 include/libipc/def.h 中配置 default_timeout，或者在 send 调用的时候传入 timeout（单位ms）

确实如你所说，因为我仅用了共享内存，进程崩溃对端是无感知的。 我一般是在signal中捕获异常情况，然后显式调用disconnect来执行清理动作。

其实我在遇到发送超时的时候，有设计清除无效（引起超时的）连接标记的机制。 当环形队列满了，仍然有数据（接收者）未完成消费，就会触发超时等待（默认100ms）。 默认环形队列255，所以我有点奇怪。。除非系统在消息通讯写满队列的这段时间里，出现二三十次接收者崩溃，否则不会出现你的这个情况。。

不是，是指发送的消息个数 段错误之类的强制退出，在运行的时候应该不会抓不到的，你看下你捕获了哪几个信号，是否有遗漏

暂时没有，我考虑加一个吧。 其实我以前的版本有这种接口，但后来我把它删掉了。 主要是粗暴的清空所有连接，有可能会导致其他问题，在这个接口的使用上必须小心，确保没有其他进程在用这个消息通道。

> 在同一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...

> 这个disconnect也会随之清理消息队列对吧? > > 所以得到这个false之后我不应该立即关闭发送端退出程序, 而是应该直接尝试重新发送数据? 对的，你看下还存活的接收端是不是收到数据了。这个提示不影响正常的接收端。

hi，请问你的编译环境、运行时的硬件环境和操作系统是怎样的？ demo/msg_que 的测试能够跑到多少每秒？