木头云

关键在于 writer 需要能识别出当前队列中的消息是否已被所有 reader 消费完。 这里有两个问题： 1. 如何得知有多少 reader？ 2. 如何标记某个 reader 已完成？ 再考虑到 reader 可能会 crash，从而导致 reader 的计数不变，因此还有新的问题： 1. 某消息一直未被消费完，如何做超时等待？ 2. 超时后，如何清除多余的未完成标记？ 权衡性能、空间占用等指标后，不同的 prod-cons（生产者-消费者）模型会采用不同的方案。 具体来说，超时默认均为 100ms；在 unicast 模式下，消息本身无记录（因为一条消息只会被消费一次），只在整体上记录了 reader...

对 broadcast 来说，每个客户端在自己的内存（而非共享内存）中保存自己的读取位置，写入者只需要保证不覆盖就好了。

不知你找的是哪里的 counter？关键代码在：`elem_array.h` 的 `connect_*/disconnect_*` 。 实际上这个检测做得很简单，新的 receiver 会增加 connections 计数（见：`elem_def.h`，`class conn_head_base`、`class conn_head`），sender 在发送消息时会实时探测 connections 计数（见`prod_cons.h`，`struct prod_cons_impl`系列的`push`方法）。而 receiver 退出会导致计数减少，若存在消息未收取完成，则将等待超时后强制覆盖。 `CreateFileMapping`可以用于创建，及打开一个现存对象（见：[CreateFileMappingW function](https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-createfilemappingw)）。所有的句柄会在进程 **正常** 退出时自动释放，你可以在`shm_win.cpp`的`release`函数里打断点确认 msg-que 的 CTRL-C。 另外目前的大msg缓存算法其实对 msg-que 这种行为不太友好，它只是为了临时偶尔一两次大msg发送，而对频繁大小不确定的大msg传输，就会导致大量句柄的创建。我已经在一个新分支[issue-17](https://github.com/mutouyun/cpp-ipc/tree/issue-17)上提交了修改，避免句柄创建过多。你可以用这个新分支上的代码测试。

哦，这里不是参考paper做的，基本是我自己想出来的方案。 后面的while循环主要是为了更新wt标记。存在多个写者的时候，不能简单的 ++wt，否则后写的先完成，会导致尚未完成的数据被读取，因此 wt 标记必须跟随着队列里最靠前的写者。

低权限用户对高权限创建的共享内存好像只能读，不能写，这样的话我现在的ipc机制肯定没办法连接了…… 可能需要针对低权限搞一个只读模式才能解决。

神奇。。我现在还在加班，明天有空看一下。。 虽然mmb性能确实比smb弱一点，但也不至于如此。 try_send是队列满了不强制发送，如果队列满了，说明接收端一直没收数据，按正常情况来说，接收端不应该这样。 所以如果接收端本来就不能收数据了，用try_send并不能让它恢复的。 目前的ipc在对共享内存的退出保护上做得很不够，我会在重构的时候重点思考下怎么增加鲁棒性。

我试了一下，跑得蛮好呀，没有复现你的被踢掉的现象。。你recv的参数是咋写的？ 你那边控制台上有打印出`force_push`么？

不会有影响~但细节我有点记不清了，建议都删掉吧

好，我这周末看看

我改了一下，你用这个分支（[issue-71](https://github.com/mutouyun/cpp-ipc/tree/issue-71)）上的代码测试下看看还有没有问题？ 根本原因： - 无参全局变量初始化时，不会同时创建内部的 mutex 对象 - main 函数内进行赋值操作，此时 mutex 对象才会被创建 - 同时，mutex 对象实现上依赖一个 static 懒单例，此单例在 mutex 对象真正创建时才会初始化 - 以上条件导致全局变量析构时，mutex 内的 static 懒单例在其之前就先析构了，从而导致内存访问异常 当前的解决方案： - 在 chan 对象初始化同时初始化 mutex 内的...