El 18/06/2014 17:03, Joseph Van Riper escribió:
I ran into a problem with message queues that, after a couple of days investigation, lead to finding this bug. I notice that the maintainer has labelled this bug as 'invalid'. I would like to convince the maintainer otherwise. My alternatives are less optimum.
It's strange that I closed it without any comment. I can't remember why I would do that, but that's clearly not the way to close a ticket. Sorry for that.
Or, alternatively, I would have to create my own message queue that doesn't rely upon std::size_t, but perhaps uses boost::uint32_t or boost::uint64_t instead... but it seems silly to me to maintain another message queue when this one is very close to being able to do what I need.
I should also point out that I need for this to work in Linux as well, although I don't expect Linux has the Windows annoyance of having to work with two different bit-wise operating systems on one box.
The problem with the message queue is that it won't work at all in Linux
between 32 and 64 bit processes because this message queue is based on
process-shared mutex and condition variables and pthread mutex and
condition variables provided by glibc are not compatible between 32 and
64 bit processes.
Changing types to It might work on Windows or Solaris, but there is no
guarantee. Message queue members could be differently placed by the 32
or the 64 bit compilers. This class is less than prepared to be shared
between 32 and 64 bit processes.
You can try this using
boost::interprocess::message_queue_t< offset_ptr
At the very least, I'd like a dialog, so I can understand why this defect is considered 'invalid'. Convince me that it really is invalid, and I'll go away. Otherwise, I respectfully argue against it.
The alternative to have a portable message queue is to implement it over POSIX message queues (which uses system calls) on Unix systems and implement a similar interface over Windows named pipes or similar. Not trivial to achieve. In general I regret putting message_queue in Interprocess, as IMHO it's not good enough to be in the library. Some people find it useful, though. Best, Ion