Boost消息队列不是基于POSIX消息队列的？无法使用select（2）吗？

Question

我想使用Boost.Interprocess的消息队列代替套接字在一台主机内进行通信。但是经过深入研究，似乎该库由于某种原因避免使用POSIX消息队列设施（我的Linux系统支持），而是在POSIX共享内存上实现。尽管接口相似，您可能不能立即猜到这一点，但似乎确实如此。

对我来说，不利的一面是通过shm_open(3)获得的共享内存似乎无法与select(2)一起使用，而POSIX消息队列通过mq_open(3)获得则可以。

在这种情况下，Boost的库似乎输了。有人知道为什么吗？即使POSIX消息队列仅适用于某些系统，我也希望Boost在可用的地方使用该设施，并仅在必要时重新实现它。是否存在我尚未认识到的POSIX系统陷阱？

- John Zwinck

Answer 1

我之前在使用Boost.Interprocess的同步类时遇到了类似的情况，特别是条件类。它是以"通用"方式实现的，但它的实现方式是使用自定义自旋锁(highly inefficient)，至少在OS X上效率非常低下。就实际效果而言，这使得同步类毫无用处。

根据我的经验，Interprocess库相当不成熟。我使用它来进行共享内存，虽然它确实运行得很好，但也有一些问题需要解决，例如动态调整共享内存等"缺失的功能"。

总之，不要期望这个库能够立即成为万能解决方案。它很好，但目前还不是特别出色。

- JKP

---

请注意，在Linux上，与使用自定义自旋锁不同，它使用pshared互斥锁和条件变量，这几乎与同一进程内的互斥锁一样高效。然而，要选择boost::interprocess对象，您需要有一个线程监视相关对象，并在有数据等待时触发fifo或eventfd。 - bdonlan

仍然没有解释为什么boost::interprocess在可用时不使用posix mqueue...我自己进行了mqueue抽象，当在win32上构建时，我的抽象使用boost::interprocess::mqueue，而在linux上构建时，我的抽象使用posix mqueue。这很容易，这就是为什么我找不到boost::interprocess不这样做的原因。不成熟？还是我忽略了什么？ - Philippe Cayouette

Answer 2

很遗憾，它不能。当我挖掘资源后，我也感到失望。

但是这个事实的另一面是好的：如果你的程序使用boost::asio，你可以将POSIX消息队列API包装为数据报数据源的另一个选项，如果它是boost::interprocess的一部分，那么（依我之见）这将是更好的选择......这可能相当复杂，但（依我之见）绝对值得这样做，因此你可以以统一的方式处理MQ并使用其他boost::asio的功能...

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

- zaufi

---

我对使用boost::asio作为消息队列的想法与你完全一致，就像你提出的那样，只是另一个数据报源。你有添加数据报源到boost::asio的经验吗？我只是通过阅读一些来自boost的源代码浅尝辄止，但我还没有找到关于这个主题的好文档/教程... - Philippe Cayouette