Boost Message Queue 不是基于 POSIX 消息队列？无法选择（2）？答案

【问题标题】：Boost Message Queue not based on POSIX message queue? Impossible to select(2)?Boost Message Queue 不是基于 POSIX 消息队列？无法选择（2）？
【发布时间】：2012-12-04 07:46:49
【问题描述】：

我想我会使用 Boost.Interprocess 的 Message Queue 代替套接字在一台主机内进行通信。但是在深入研究之后，这个库似乎出于某种原因避开了 POSIX 消息队列工具（我的 Linux 系统支持），而是在 POSIX 共享内存之上实现。界面非常相似，您可能不会马上猜到，但似乎确实如此。

对我来说，缺点是通过shm_open(3) 获得的共享内存似乎不适用于select(2)，这与通过mq_open(3) 获得的POSIX 消息队列相反。

在这种情况下，Boost 的库似乎失败了。有谁知道为什么会这样？即使 POSIX 消息队列仅在某些系统上可用，我希望 Boost 在可用的地方使用该工具，并仅在必要时重新实现它。 POSIX 系统是否存在一些我还不认识的缺陷？

【问题讨论】：

标签： select boost message-queue interprocess epoll

【解决方案1】：

前几天我在使用 Boost.Interprocess 的同步类时遇到了类似的情况：即条件类。它以“通用”方式实现，但其实现方式是使用自定义自旋锁，高度效率低下（至少在 OS X 上）。出于所有意图和目的，它使同步类毫无用处。

根据我的经验，Interprocess 库还很不成熟。我将它用于共享内存，它确实工作得很好，但有一些粗糙的边缘，我不得不修改一些“缺失的功能”，例如动态调整共享内存的大小等。

总之，不要指望这个库是灵丹妙药。这很好，但目前并不例外。

【讨论】：

请注意，在 Linux 上，它不是使用自定义自旋锁，而是使用 pshared 互斥锁和条件变量，这应该几乎与同一进程中的互斥锁一样有效。但是，要在 boost::interprocess 对象上进行选择，您需要有一个线程监控相关对象，并在有一些数据等待时触发 fifo 或 eventfd。
仍然没有解释为什么 boost::interprocess 在可用时不使用 posix mqueue...我自己做了一个 mqueue 抽象，在 win32 上构建时，我的抽象使用 boost::interprocess:: mqueue，在 linux 上构建时，我的抽象使用 posix mqueue。这很容易，这就是为什么我找不到 boost::interprocess 不这样做的原因。不成熟？我监督了什么？

【解决方案2】：

是的，不幸的是它没有。当我在挖掘资源后意识到这一点时，我也很失望。

但这是事实的另一（好的）方面：如果您的程序使用boost::asio，您可以将 POSIX 消息队列 API 包装为 只是另一个 数据报 数据源如果它是boost::interprocess 的一部分，这个（恕我直言）会更好用......这将是非常重要的，但是（恕我直言）绝对值得这个，所以你可以使用 MQ 以统一的方式工作并且使用其他boost::asio 东西的power...

...在我的下一个项目中，如果我再次需要 POSIX MQ，我肯定会采用这种方式 :)

【讨论】：

我对使用 boost::asio 消息队列有同样的想法，正如你所建议的那样，只是另一个数据报源。您是否有任何将数据报源添加到 boost::asio 的经验？通过阅读 boost 的一些源代码，我几乎没有触及这个主题的表面，但我还没有找到关于这个主题的好的文档/教程......