我以爲我會使用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