enayzhu

我就是用的demo中的 send_recv 例子，只修改了channel 类型，其他都没有修改，进行的测试。在x86平台上确实不容易出现，可以将发送间隔继续缩短尝试下。 我还有个问题请教下，就是我发现当程序异常推出的时候可能会残留文件，有时候会影响程序的再次运行，所以我自己作了个机制去删除残留共享文件，但是我发现有两个共享文件并不是由创造channel 时传入的name 组成的，而且当存在多个发送端和接收端的时候这两个文件只有一份，“__IPC_SHM____CA_CONN__” 和 “__IPC_SHM____CHUNK_INFO__1024” ，如果程序异常推出了，这两个文件不进行删除，其他的以创造channel 时传入的name 组成的文件全部删除掉了，当程序重新启动后会不会产生一些影响？多谢@mutouyun

你好mutouyun，目前遇到了一个问题，我发送的数据大小会经常变化，就产生了非常多的 __IPC_SHM____CHUNK_INFO__xxx 文件。我通过修改 enum : std::size_t { data_length = 64, large_msg_limit = data_length, large_msg_align = 1024, large_msg_cache = 32, }; 这个枚举中的字段是否可以控制，减少些__IPC_SHM____CHUNK_INFO__xxx 文件的生成？ 当前的配置中超过64字节就会用新建临时的共享内存 发送，就会产生新的__IPC_SHM____CHUNK_INFO__xxx 文件是这个意思么？ 至于large_msg_align 和 large_msg_cache 的含义是什么？多谢@mutouyun