木头云
你是不是有重启过发送或接收端？目前的实现对重启很不友好。
ff250cd7acd3bbaa2d6038da4750977e5cdd1e42 3aac7bea08f2b0842b15c6e4b7d5b04e2602efa9 e60f856295b063cdc2f2b3a95f4bae238edf537a fc6f28a8868cb0c921046cf961535d9e5e360ac4
e7262af0db83091dfa4bdcf51d9b5451493fa697 649a5ee02a311988fdf8404f163eb1575ad814d5 d17aeaae1e8815a9860930d42e8b66e0d999194f f8fdfb0f5738156fb0ecb586f298b385aa33c569
spin lock。。记下来了，重构版本我想想有没有什么好办法。 到时候要不直接用 robust mutex，要不就想办法无锁。 large生命周期那个，必须想办法识别是否能真正回收，现在看起来似乎没什么好办法。不过确实是个问题，需要仔细思考下方案。
哈哈，谢谢，我不知道啊 我这个库好久没管了，请问贵司是？
其实核心就是这个文件：src/libipc/prod_cons.h，这里面的策略都是各种定长无锁队列。 然后对于大内存，在队列中只存一个索引号，然后通过索引去取真正的内存。
麻烦的是没数据的时候怎么等待，这个位置不能忙等，所以不是无锁的。
1）听起来你需要的是rpc，可以通过在堵塞的ipc send上自己定义一层协议来实现。简单的一个做法可以是在自己发的消息加个序号，对端收到以后在ack消息里回过来，recv的时候取出来比较一下，不一致的丢掉就可以了（因为堵塞，所以不一致的都不是自己发的）。 2）小内存拷贝两次，大内存拷贝一次。大小内存的界限默认是64字节。发送的时候由于我没有提供共享内存池指针供数据写入，因此数据会拷贝一次到共享内存里。recv的时候，返回buff_t，指针的生命周期跟着buff_t对象走。此时对于小内存会再次拷贝一次；对于大内存，内部仅有共享内存的指针，不会发生拷贝，因此一直持有对象不释放的话，对于大内存来说会导致一个共享内存槽位无法回收。默认相同大小的槽位只有255个，超出了就会导致大内存也发生拷贝（因为无法一次性传输，会进行拆包，并在进程中分配堆内存来缓存接到的数据包），引起性能骤降。
看起来是析构时序的问题。你的`_register`对象是一个全局变量，它的析构发生在库内部全局对象之后，导致内存访问异常。比如改成这样就不会有问题了： ```c++ #include #include #include #include #include #include #include #include #include #include "libipc/ipc.h" // #include "capo/random.hpp" using msg_que_t = ipc::chan; class shared_memory_register { public: shared_memory_register() {} ~shared_memory_register() {} bool add_shared_memory(std::string...