[interprocess] 32 to 64 bit ?
Hi there,
before holidays kick in I wondered whether I go for a strange problem in my usage of interprocess. Im using it within boost 1.38 on windows, msvc.
Basically, I transfer data between two processes, which works great. So far, both have been built 32 bit release. But now since I exclusively use supposedly safe data types in the shared mem such as boost::uint32_t and friends I was wondering whether it's possible to have the data retrieving process built in 64 bit and access the same buffer.
I just gave it a shot and it behaves different to what I had hoped for.
In blocks during finding a struct with in a shared segment.
ret = segment->find<struct my_buffer>(unique_instance).first;
This operation blocks on a mutex in segment_manager.hpp:
#ifdef BOOST_INTERPROCESS_RVALUE_REFERENCE
scoped_lock<rmutex>
#else
detail::move_return
Stephan Menzel wrote:
The code is the same as in my 32 - 32 bit versions and known to work. Now I'm wondering, is this supposed to work or is 32 to 64 bit transfer not supported at all? Is this a bug or a feature? Do I have to have both applications in a 64 bit version?
There is no support for 32bit-64bit communications. You would need to use much lower level utilities, like mapped_regions to do that. Internal structures have platform-dependent sizes (e.g.: offset_ptr needs to be bigger in 64 bit systems because it has to address much bigger address space).
I was very excited about using the interprocess library to solve a set of problems in our current project, until I saw this post. We have to support 32 and 64 bit binaries. Falling back to using the low level utilities like mapped_region means that much of the appealing functionality from the interprocess library is unavailable to us. I understand that certain functionally between different sized address spaces doesn't make sense. A very large shared space from a 64 bit process would not be addressable in 32 bits. But I doubt that people are really using this library to share address spaces larger than 4 gig. More than likely developers want to share comparatively small amounts of data between processes. Is there any plan to add support for 32/64 bit in the future? Best, -- Allen Cronce On Apr 9, 2009, at 1:04 PM, Ion Gaztañaga wrote:
Stephan Menzel wrote:
The code is the same as in my 32 - 32 bit versions and known to work. Now I'm wondering, is this supposed to work or is 32 to 64 bit transfer not supported at all? Is this a bug or a feature? Do I have to have both applications in a 64 bit version?
There is no support for 32bit-64bit communications. You would need to use much lower level utilities, like mapped_regions to do that.
Internal structures have platform-dependent sizes (e.g.: offset_ptr needs to be bigger in 64 bit systems because it has to address much bigger address space). _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Mon, Apr 20, 2009 at 07:53:47AM -0700, Allen Cronce wrote:
of problems in our current project, until I saw this post. We have to support 32 and 64 bit binaries. Falling back to using the low level
On the same machine, under the same OS? Out of curiosity, what circumstances force you to share memory between 32- and 64-bit processes? Are all participant processes developed by you?
process would not be addressable in 32 bits. But I doubt that people are really using this library to share address spaces larger than 4 gig. More than likely developers want to share comparatively small
The limit is much less than 4G. Kernel wants some share of address space for itself, all (priavte) memory allocations eat up address space, add to that potential file mappings.. But this is an inherent problem with 32-bit address spaces.
Hi Zejko,
On the same machine, under the same OS?
Yes. This is not unusual, especially on Mac OS X. With each successive OS version, Apple has pushed more and more towards 64 bits. But this won't happen overnight, and the result is that 32 and 64 bit executables have to coexist.
Out of curiosity, what circumstances force you to share memory between 32- and 64-bit processes?
We have a 32 bit daemon, and both 32 and 64 bit client processes that need to communicate with the daemon.
Are all participant processes developed by you?
In some cases, no. Customers of ours will be able to use our libraries in 32 and 64 bit binaries that they create.
The limit is much less than 4G. Kernel wants some share of address space for itself, all (priavte) memory allocations eat up address space, add to that potential file mappings.. But this is an inherent problem with 32-bit address spaces.
From a pragmatic perspective, I agree. Certainly in our specific case we only want to share a small amount of memory between processes (regardless of their addressing size), which I would think is typical for most IPC uses. Best, -- Allen Cronce
Allen Cronce wrote:
I was very excited about using the interprocess library to solve a set of problems in our current project, until I saw this post. We have to support 32 and 64 bit binaries. Falling back to using the low level utilities like mapped_region means that much of the appealing functionality from the interprocess library is unavailable to us.
Yes, you loose a lot of funcionality, but
I understand that certain functionally between different sized address spaces doesn't make sense. A very large shared space from a 64 bit process would not be addressable in 32 bits. But I doubt that people are really using this library to share address spaces larger than 4 gig. More than likely developers want to share comparatively small amounts of data between processes.
Is there any plan to add support for 32/64 bit in the future?
It's not that I don't find it interesting, especially the goal of having (if the ABI of two compilers is the same) portable managed segments (all internal poitners might be offset_ptr_32 or uint32_t, etc...). That would allow also quite portable (supposing alignment is correctly configured in the compilers) mapped files. But this requires a huge effort (I would need to rewrite all the allocation algorithms, containers, allocators, etc...) and I don't have time to implement this type of costly features. Best, Ion
participants (4)
-
Allen Cronce -
Ion Gaztañaga -
Stephan Menzel -
Zeljko Vrba