POSIXメッセージキューに基づいていないメッセージキューをブーストしますか？ select（2）が不可能ですか？

Question

Boost.Interprocessの 1つのホスト内の通信用ソケットの代わりにメッセージキュー。しかし、掘り下げた後、このライブラリは何らかの理由でPOSIXメッセージキュー機能（私のLinuxシステムがサポートする）を避け、代わりにPOSIX共有メモリ上に実装されているようです。インターフェースはよく似ているので、すぐには推測できないかもしれませんが、そうだと思われます。

私にとっての欠点は、 shm_open（3）で取得した共有メモリが、POSIXメッセージキューではなく、 select（2）で使用できないように見えることです。 mq_open（3）経由。

この場合、Boostのライブラリは失われたようです。なぜこれが必要なのか誰もが理解していますか？ POSIXメッセージキューが一部のシステムでのみ利用できる場合でも、Boostは利用可能な場所でその機能を使用し、必要な場合にのみ再実装することを期待しています。まだ認識していないPOSIXシステムの落とし穴はありますか？

Answer 1

先日、Boost.Interprocessの同期クラス、つまり条件クラスを使用したときに、同様の状況に遭遇しました。 「汎用」で実装されています。方法ですが、それが行われた方法は、（少なくともOS Xで）非効率的な非常にカスタムスピンロックを使用することです。すべての意図と目的のために、同期クラスは役に立たなくなりました。

私の経験では、プロセス間ライブラリはかなり未熟です。私は共有メモリにそれを使用し、それはかなりうまく機能しますが、いくつかの荒いエッジがあり、いくつかの「欠けている機能」をハックする必要がありました。共有メモリなどの動的なサイズ変更など。

要約すると、このライブラリがまだ特効薬になるとは思わないでください。良いですが、現時点では例外ではありません。

Answer 2

はい、残念ながらできません。情報源を掘った後、それを知ったときも失望しました。

しかし、この事実の別の（良い）側面があります：プログラムが boost :: asio を使用する場合、POSIXメッセージキューAPIをちょうど別のデータグラムデータソースで、これが boost :: interprocess の一部である場合は、この（IMHO）を使用するのがさらに良いでしょう。...（IMHO）間違いなくこれに値するので、MQで統一された方法で作業し、他の boost :: asio のものの power を使用できます...

...次のプロジェクトでPOSIX MQが再び必要になった場合、間違いなくこの方法を使用します：）