木头云
Yes, it is a defect. There is a certain probability that a working connection will be closed while cleaning up invalid connections. I'm thinking of some solutions to this problem.
是因为锁异常导致的问题么？ 你可以尝试下develop分支下的代码，在那个里面我尝试了robust的锁和条件变量。 如果还有问题，还请及时告知我，谢谢~
/dev/shm下的所有文件删除后依然存在这个问题？这不应该啊…… 我估计12月可能能有时间正式开始对应这一系列严重bug。
你可以尝试下develop分支下的代码，在那个里面我换掉了底层的sync实现。
挂在相同的地方吗？应该不同吧，毕竟sync的代码都完全变了 请问有最小复现代码么？还是说在你的环境里，只要写全局变量，退出就崩溃？ 是linux下的g++么？
看起来有点神奇。。可能是哪里有低级bug 我最近比较忙，等我有空了看一下
暂时没有哦 你可以看下里面和跨平台有关的部分，我基本都有用宏和文件做隔离，你可以自己实现一套mac支持
嗯。。我这个库里的内存池其实是比较简单的，主要是考虑到在不引入任何第三方内存池时的性能问题。 实现方式类似 boost::pool。如果你有看过 Andrei Alexandrescu 的老书 Modern C++ Design，这里的设计是很容易懂的。 默认是不回收内存给系统的（简单来说就是一直缓存最大内存水位，这样做有好处也有坏处），在一些复杂场景下可能会导致内存占用过高。 如果你有使用 tcmalloc 之类的高性能内存池，可以把 cpp-ipc/src/libipc/memory/resource.h 里的 async_pool_alloc 改成 static_alloc，这样会使用系统默认的内存分配器（tcmalloc 会自动接管默认分配器），不会只分配不回收了。
咦。。你是怎么改的？是改成 static_alloc 了吗？ 你的发送频率最高是多少？可以告诉我你的测试方法么？或者简单的 demo，我这边复现一下试试？ 广播是通过在数据结构里记录客户端的标记（1个bit），取过的标记就清理掉，全部取完了数据才能覆盖。
啊，不能只改这个，你只需要把`async_pool_alloc`改掉： ```c++ using async_pool_alloc = static_alloc; template using allocator = allocator_wrapper; ```