Boost logo

Boost Users :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-02-01 16:50:28


Richard Brown wrote:
> Ion,
>
>
> I have a server process and multiple client processes which
> successfully share a managed_shared_memory vector as well as two message_queues.
> All processes are 32-bit, and run under both Windows XP and 64-bit XP Server (using 32-bit Wow emulation).
>
>
> However I am trying to take advantage of the Windows XP 64-bit
> OS, so I have attempted to build the Server process as 64-bit, while leaving the client processes at 32-bit (unfortunately I'm stuck with some 32-bit libraries and cannot move the client processes to x64 at this time).
>
> Both the server and clients (64 bit and 32 bit respectively) can see the shared memory file that
> Interprocess creates, and my class members use fixed-sized
> datatypes (__int32, __int64), but after walking some of the code it
> became apparent that Interprocess is having issues with mixing the different processes.

Interprocess managed shared memory is dependent on the ABI of the
compiler so it won't be able to share data structures between 64 bit and
32 processes. It's a design decision: I haven't designed it to be
compatible, because internal bookeeping data uses std::size_t and void*
members in order to simplify implementation and improve performance.

On the other hand, I think that users will expect message queues to be
compatible between 32 and 64 bit programs and I don't think they are.
Unfortunately I'm afraid there is no time to program and test those
changes for Boost 1.35.

The design of compiler or 32/64 bit compilation agnostic managed shared
memory and memory mapped files seems to be very useful, but it does not
seem very easy. C++ has no standard ABI and even if most compilers seem
to be quite compatible for ADT types, there is no compatibility
guarantee. I'll put it in my to-do list.

Sorry about the bad news ;-)

Regards,

Ion


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net