Linux下Boost message_queue能否实现32/64位进程间通信？

一、Boost message_queue跨位通信的可行性 #

Boost message_queue不适合直接用于32位与64位进程间通信，核心原因是其内部元数据（如消息长度、队列控制结构）依赖于进程的字长（32位与64位下size_t、指针等类型的内存占用不同），导致两端对队列结构的解析完全不一致。即使手动对齐消息体的结构，队列内部的控制头仍会因字长差异出现解析错误，最终触发interprocess_exception异常。

虽然理论上可以通过修改Boost内部代码、强制使用固定位宽类型定义元数据来规避，但操作复杂度极高，且无法保证版本兼容性，不建议采用。

二、Linux下支持接收超时的跨位IPC替代方案 #

以下方案均原生支持32/64位进程通信，且能实现接收超时：

1. POSIX消息队列（mq系列API） #

• 原生Linux API，跨位兼容性好：接口使用固定大小的整数类型（如mq_attr结构体字段采用long或固定位宽类型），32位与64位进程可直接交互。
• 接收超时实现：通过mq_timedreceive()函数，传入struct timespec结构体指定超时时间。
• 注意事项：两端需使用相同的队列名称、消息最大长度及权限配置。

2. Unix域套接字（Unix Domain Socket） #

• 跨位通信无压力：以字节流/数据报模式传输数据，两端可自行按约定的二进制格式解析，不受字长影响。
• 接收超时实现：
  • 方式一：设置套接字的SO_RCVTIMEO选项，指定超时时间。
  • 方式二：结合select()/poll()/epoll()监听套接字可读事件，同时设置超时参数。
• 优势：灵活性高，支持传递文件描述符，适合复杂通信场景。

3. 共享内存+同步原语 #

• 共享内存本身无跨位障碍：只要两端用固定位宽类型（如uint32_t、int64_t）定义共享数据结构，即可保证内存布局一致。
• 接收超时实现：
  • 结合sem_timedwait()：用信号量同步，调用时指定超时时间。
  • 结合pthread_cond_timedwait()：配合互斥锁实现条件等待，设置超时参数。
• 优势：适合大数据量传输，性能开销低，但需自行处理数据同步与一致性逻辑。

内容的提问来源于stack exchange，提问作者hczstev