8

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?

4

2 に答える 2

4

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

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

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

于 2009-01-08T12:53:11.203 に答える
2

ええ、残念ながらそうではありません。ソースを掘った後、それを知ったときもがっかりしました。

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

...次のプロジェクトでPOSIXMQが再び必要になった場合は、間違いなくこの方法を採用します:)

于 2012-12-03T23:46:49.497 に答える