我以为我会使用Boost.Interprocess的Message Queue代替一个主机内的通信套接字。但在深入研究之后，似乎由于某种原因该库避开了POSIX消息队列工具（我的Linux系统支持），而是在POSIX共享内存之上实现。界面非常相似，你可能不会马上猜到，但似乎是这样。Boost消息队列不基于POSIX消息队列？不可能选择（2）？
我的缺点是，通过shm_open(3)获得的共享内存看起来不适用于select(2)，与通过mq_open(3)获得的POSIX消息队列不同。
看来Boost的图书馆在这种情况下失败了。有谁明白知道为什么这应该是？即使POSIX消息队列仅在某些系统上可用，我也希望Boost在可用的地方使用该设施，并仅在必要时重新实现。我还没有意识到POSIX系统有什么缺陷吗？
当我使用Boost.Interprocess的同步类时，我遇到了类似的情况：即条件类。它是以“通用”方式实现的，但其实现方式是使用自定义螺旋锁，其效率很低，至少在OS X上是低效的。对于所有意图和目的，它使同步类无用。
根据我的经验，Interprocess库相当不成熟。我用它来共享内存，并且它工作得很好，但是有一些粗糙的边缘，我不得不绕过一些“缺少的功能”，例如动态调整共享内存等。
总之，不要希望这个图书馆能够成为一颗银子弹。这很好，但在这个时候并不例外。
是的，不幸的是它没有。在挖掘消息来源后，我也很失望。
但这里是这个事实其他（好）的一面：如果你的程序使用boost::asio你可以换POSIX消息队列API为只是一个报数据源这（恕我直言）甚至会更好用如果它是boost::interprocess的一部分...这将是相当不平凡的，但（恕我直言）绝对值得这一点，所以你可以工作瓦特/ MQ统一的方式，并使用电源其他boost::asio东西...
...在我的下一个项目中，如果我再次需要POSIX MQ，我一定会采取这种方式:)
请注意，在Linux上，不使用自定义螺旋锁，而是使用pshared互斥锁和条件变量，这应该与同一进程中的互斥锁效率几乎一样。但是，要选择`boost :: interprocess`对象，您需要有一个线程监视有问题的对象，并在有些数据正在等待时碰撞fifo或eventfd。 – bdonlan 2009-08-17 14:50:28
仍然没有解释为什么boost :: interprocess在可用时不使用posix mqueue ...我自己做了一个mqueue abstration，当我在win32上构建时，我的抽象使用boost :: interprocess :: mqueue，并且在linux上构建时，我的抽象使用posix mqueue。这很容易，这就是为什么我找不到boost :: interprocess不这样做的原因。不成熟？我监督的东西？ – 2013-03-06 17:47:28