木头云
可以的，通过`system`调用`sudo rm -rf /dev/shm/__IPC_SHM___*`
我最近没怎么上github……要不你邮件发我微信吧，我加你聊下
额，是的，主要是异常退出导致的。。根本原因有如下几个方面： 1. 目前的机制是尽量保证不丢消息，因此存在接收端尚未读取的消息时会进行等待，故而非法退出的接收端会卡住整个队列； 2. linux下pthread的condition在非法退出后无法恢复（这个我好像有一个ut测试这种情况）； 3. 存在原子循环锁，非法退出导致锁未释放。 如上这几个情况里，1需要对实现做重构，并定义出不同预期的接口；3需要考虑用无锁结构重构这部分原子锁代码；2我暂时没想出啥好办法解决=.= 我最近半年太忙了，而且暂时看不到头，基本没啥时间改代码。如果你有好的点子，可以帮我提提pr……
我其实在wiki里有写这个 https://github.com/mutouyun/cpp-ipc/wiki/%E5%85%A8%E5%B1%80%E5%B8%B8%E9%87%8F%E5%AE%9A%E4%B9%89
mark，在现有master分支上比较麻烦
hi，最近在一个新的issue里出了类似的问题（[issue-105](https://github.com/mutouyun/cpp-ipc/issues/105)），但他的问题是windows服务和普通进程之间的交互，本质应该不是权限问题，我的解决方案最终还是加上Global前缀，不清楚对本问题是否有影响。 如果我的方案两位其实尝试过，对次问题没帮助，那这个issue后面的方案应该还是必须想办法加只读的监听channel才能解决。 pr：https://github.com/mutouyun/cpp-ipc/pull/106
很不错的想法，但32的限制问题并不是出在用于存储连接的`ids_`上，而是我们需要原子的标记某个recv的读取状态。 如果连接数超过限制，我们很难用原子操作对状态做查询了。 你给的connect、disconnect有点问题，多线程同时处理的时候有bug。 不过我想了下，思路应该是可行的，只是循环里的并发访问需要写对。 另外，我们在这种情况下就不应该用位来标记recv，而用一个数值（32位），所以还需要改下prod_cons的实现。
1、发送端在发送消息的时候，如何知道有有哪几个客户端，退出了连接，是怎么实现的。 》channel会创建一个计数器 2、对于高频的发送是否支持，比如发送周期是10ms一次的，循环发送。这样会不会导致内存泄露。 》10ms频率不是很高。只要你接收端处理足够及时，没问题 3、在高频(20m
其实倒不是内存泄漏，计数器无法改变会导致发送端长时间等待接收端。 目前的做法是超时会自动清理一次连接标记。 但由于清理动作本身不是无锁的（其实是没考虑清理的同时出现新的接收端），异常退出再启动很容易出问题。 另外还有一些对异常退出很不友好的 bug，参看：https://github.com/mutouyun/cpp-ipc/issues/79 https://github.com/mutouyun/cpp-ipc/issues/88
gcc5编译报错吗？开了c++14的编译支持吗？