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?

Ephemeris

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.

Simplistic

Note that on Linux, instead of using a custom spinlock it uses pshared mutexes and condition variables, which should be almost as efficient as mutexes within the same process. However, to select on boost::interprocess objects, you will need to have a thread monitor the object in question and bump a fifo or eventfd when there's some data waiting. – Myrt

Still, no explanation as to WHY boost::interprocess does not use posix mqueue when available... I did an mqueue abstration myself that when building on win32, my abstraction uses boost::interprocess::mqueue and when building on linux, my abstraction uses posix mqueue. That was easy, this is why I cannot find a reason why boost::interprocess don't do the same. Immaturity? Something I oversaw? – Simitar

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 :)

Offshoot

I had the same idea about using boost::asio for message queue, exactly as you propose, as just another datagram source. Did you had any experience adding a datagram source to boost::asio? I have barely scratched the surface of the subject by reading some source code from boost, but I have yet to find good docu/tutorial on the subject... – Simitar