|
Boost : |
Subject: [boost] [interprocess] Ticket 9414 (32 process communicating with 64 process)
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2014-06-18 11:03:01
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.
I am working on a project where, on a Windows machine, I am running a
service that waits for messages on the message queue. On a 32-bit
environment, I will not run into any problems. But in a 64-bit
environment, I may have either 64-bit or 32-bit clients attempting to write
to the message queue, due to the nature of my needs and the nature of the
Windows operating system. The messages from the clients are not specific
to the bit-ness of the client, but are sent to the server. The server
records these messages to a database it maintains. The server then pulls
messages from the database and posts it to a web page.
As the code stands now, I will have to compile both a 32-bit and 64-bit
version of the server to install on 64-bit WinOS boxes, maintaining two
separate databases of similar information, which will post to the web site
with no sense of co-ordination (and little hope of co-ordination since they
can't talk to each other).
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.
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.
- Trey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk