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?
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.