Boost Message Queue not based on POSIX message queue? Impossible to select(2)?

Question

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?

Answer 1

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.

Answer 2

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 of boost::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 other boost::asio stuff...

... in my next project if I would need POSIX MQ again, I'll definitely take this way :)