Boost Message Queue不是基于POSIX消息队列？ 无法选择(2)？
我想我会使用Boost.Interprocess的 消息队列代替套接字用于一台主机内的通信。 但深入研究后，似乎这个库出于某种原因避开了 POSIX 消息队列工具（我的 Linux 系统支持），而是在 POSIX 共享内存之上实现。 界面非常相似，您可能不会立即猜到这一点，但情况似乎确实如此。
对我来说，缺点是通过 shm_open(3) 获得的共享内存似乎无法与 select(2) 一起使用，这与通过 获得的 POSIX 消息队列不同>mq_open(3)。
看起来 Boost 的库在这种情况下失败了。 有谁知道为什么会这样吗？ 即使 POSIX 消息队列仅在某些系统上可用，我也希望 Boost 在可用的地方使用该设施，并仅在必要时重新实现它。 POSIX 系统是否存在一些我尚未认识到的陷阱？
I thought I'd use Boost.Interprocess's Message Queue in place of sockets for communication within one host. But after digging into it, it seems that this library for some reason eschews the POSIX message queue facility (which my Linux system supports), and instead is implemented on top of POSIX shared memory. The interface is similar enough that you might not guess this right away, but it seems to be the case.
The downside for me is that shared memory obtained via shm_open(3) does not appear to be usable with select(2), as opposed to POSIX message queues obtained via mq_open(3).
It seems like Boost's library loses in this case. Does anyone understand know why this should be? Even if it POSIX message queues are only available on some systems, I'd expect Boost to use that facility where it is available, and reimplement it only where necessary. Is there some pitfall of the POSIX system which I do not yet recognize?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
前几天我在使用 Boost.Interprocess 的同步类时遇到了类似的情况：即条件类。 它以“通用”方式实现，但其实现方式是使用自定义自旋锁，这种方式非常效率低下（至少在 OS X 上）。 出于所有意图和目的，它使同步类毫无用处。
根据我的经验，Interprocess 库还相当不成熟。 我将它用于共享内存，它确实工作得很好，但有一些粗糙的边缘，我不得不解决一些“缺失的功能”，例如动态调整共享内存的大小等。
总之，不要指望这个库还只是一颗银弹。 这很好，但目前并不例外。
I ran into a similar situation the other day when using Boost.Interprocess' sync classes: namely the condition class. It's implemented in a "generic" manner, but the way it has been done is to use a custom spinlock which is highly inefficient (on OS X at least). For all intents and purposes it made the sync classes useless.
In my experience the Interprocess library is pretty immature. I use it for shared memory, and it does work pretty well but there are some rough edges and I've had to hack around some "missing features" such as dynamically resizing shared memory etc.
In summary, don't expect this library to be a silver bullet just yet. It's good, but not exceptional at this time.
是的，不幸的是事实并非如此。 当我在挖掘资源后意识到这一点时，我也很失望。
但这个事实的另一（好的）方面是：如果您的程序使用
boost::asio，您可以将 POSIX 消息队列 API 包装为只是另一个数据报数据源，如果它是 boost::interprocess 的一部分，这个（恕我直言）会更好用......这将是相当不平凡的，但（恕我直言）绝对值得这个，所以你可以以统一的方式使用 MQ 并使用其他boost::asio的power......在我的下一个项目中如果我需要的话再次使用 POSIX MQ，我一定会采取这种方式:)
Yeah, unfortunately it doesn't. I also was disappointed when realize that after digging sources.
But here is other (good) side of this fact: if your program uses
boost::asio, you may wrap POSIX message queues API as just another datagram data source and this (IMHO) would be even better to use if it were a part ofboost::interprocess... it would be quite non trivial, but (IMHO) definitely deserves this, so you may work w/ MQ in a unified way and use power of otherboost::asiostuff...... in my next project if I would need POSIX MQ again, I'll definitely take this way :)