Re: [boost] [interprocess] Ticket 9414 (32 process communicating with 64 process)

Subject: Re: [boost] [interprocess] Ticket 9414 (32 process communicating with 64 process)
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2014-06-18 16:56:04

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<void, boost::int32_t, 
boost::uint64_t>>  as your message queue.

> 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