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