wait infinite when sender or receiver quit. about cpp-ipc HOT 6 CLOSED

这不是特别的使用场景，是正常的路径，这应该是个bug

from cpp-ipc.

对的，因为异常退出，仅靠共享内存自身没办法知道是否有客户端挂了。而广播又依赖所有客户端全部接收完毕，做不到真正无锁。

目前暂时没有处理这种崩溃逻辑的完美方法。
如果有什么好的建议可以提给我，我会在后续尝试改进，谢谢！

from cpp-ipc.

我的使用场景比较简单，也就一个生成者一个消费者。我解决这个问题的临时解决方案，在recv() ，send()之前加锁。这个对于一个生成者一个消费者性能影响应该不大。所以感觉够用。

添加timeout
一般IO处理都会有timeout。我看到recv() ，send()里面的逻辑，有碰到进程异常退出时，会一直while yield sleep，能否引入timeout，来剔除挂掉的客户端或服务端，来打破阻塞，返回error code.。定时间隔的semaphore有锁检测代价低。

如何去除依赖
广播方式，导致服务端依赖所有客户端。我猜测这种设计方式应该是基于性能考虑吧？ 能否有某种设计打破这种依赖关系，客户端或服务端挂了互不影响。比如每个消费者存在一个mq,生产者只负责统一更新所有的mq，生产者消费者互不影响？ 又能做到无锁和高性能？

from cpp-ipc.

如果你的使用场景是单对单（spsc）的话，那就好办了。
你看ipc.h中的定义：

using route = chan<ipc::wr<relat::single, relat::multi, trans::broadcast>>;
using channel = chan<ipc::wr<relat::multi, relat::multi, trans::broadcast>>;

你只需要自定义一个这个：

using spsc_msg_queue = chan<ipc::wr<relat::single, relat::single, trans::unicast>>;

就可以满足你的需求，消息收发是无锁的。
默认的route和channel都是基于广播模式的；点对点的话，单播即可（点对点不可能广播）。

我确实计划近期再做一次重构，将timeout加进去。
之所以一开始没加这个，是因为我在公司里的使用场景不允许丢消息。

你说得很对，我不想让发送者轮询所有客户端去发消息。后面可能我会考虑试试轮询的方式性能是否可以满意。

目前的设计里，是不会忙等待的。while yield 4k次左右后，会调用wait，使用进程间的condition或semaphore进行等待。这样做是为了在消息不频繁的时候避免无谓的cpu消耗。

from cpp-ipc.

超时已添加。

from cpp-ipc.

我的使用场景比较简单，也就一个生成者一个消费者。我解决这个问题的临时解决方案，在recv() ，send()之前加锁。这个对于一个生成者一个消费者性能影响应该不大。所以感觉够用。

添加timeout
一般IO处理都会有timeout。我看到recv() ，send()里面的逻辑，有碰到进程异常退出时，会一直while yield sleep，能否引入timeout，来剔除挂掉的客户端或服务端，来打破阻塞，返回error code.。定时间隔的semaphore有锁检测代价低。

如何去除依赖
广播方式，导致服务端依赖所有客户端。我猜测这种设计方式应该是基于性能考虑吧？ 能否有某种设计打破这种依赖关系，客户端或服务端挂了互不影响。比如每个消费者存在一个mq,生产者只负责统一更新所有的mq，生产者消费者互不影响？ 又能做到无锁和高性能？

我不太理解在recv()和send()之前加锁如何解决客户端异常退出问题，是否方便解释一下？

from cpp-ipc.