Re: [boost] boost] [interprocess] [Shared memory] STL containers and boost interprocess allocators
Is it possible to use boost interprocess' shared memory allocator with the normal STL containers that come with standard C++ build environments (gcc on Linux and Solaris, Visual C++ on Windows, etc.)? I know that there might be an issue with some STL containers not properly supporting encapsulated pointers that handle offset differences in memory addresses. Is this the reason why interprocess has its own containers?
You might like to have a look at this thread where I asked the GNU libstdc++ people about this: http://thread.gmane.org/gmane.comp.gcc.libstdc++.devel/12919 This pre-dates Boost's shared memory library which I now use. Phil.
You might like to have a look at this thread where I asked the GNU libstdc++ people about this:
Thanks for the reply. I was just wondering: my problem will be solved if I can ensure that the shared memory is mapped to the same virtual memory address range in all processes that access it. Do you know of any way this can be done in Linux and Solaris? I have full control of how the programs will be compiled and linked, if any change at that level is necessary. It may not be the most general solution, but it'll work in my case. I realize that this discussion is beginning to veer off topic, and this will be my last email on this! Thanks and regards, Vishnu ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
Vishnu M Menon wrote:
You might like to have a look at this thread where I asked the GNU libstdc++ people about this:
Thanks for the reply.
I was just wondering: my problem will be solved if I can ensure that the shared memory is mapped to the same virtual memory address range in all processes that access it.
Do you know of any way this can be done in Linux and Solaris? I have full control of how the programs will be compiled and linked, if any change at that level is necessary. It may not be the most general solution, but it'll work in my case.
UNIX mmap offers the way to map a shared memory segment at a fixed address. Boost.Interprocess also offers this possibility. You can use fixed_managed_shared_memory class to create a shared memory segment with object construction capabilities (just like managed_shared_memory), whose allocators will define pointer like a raw pointer, and that can be mapped at a fixed address. Take this example: http://ice.prohosting.com/newfunk/boost/libs/interprocess/doc/html/interproc... tiny url: http://tinyurl.com/2ks5yx and change it replacing: managed_shared_memory --> fixed_managed_shared_memory boost::interprocess containers --> stl containers The line managed_shared_memory shm(create_only, "myshm", 10000); with fixed_managed_shared_memory shm(create_only, "myshm", 10000, --> /*mapping address*/); With these changes you will be able to use boost.interprocess allocators with stl containers and map all in a fixed address in all processes. I think this should be added as a new chapter in the next Interprocess version. I hope this helps, Ion
boost::interprocess containers --> stl containers
The line
managed_shared_memory shm(create_only, "myshm", 10000);
with
fixed_managed_shared_memory shm(create_only, "myshm", 10000, --> /*mapping address*/);
With these changes you will be able to use boost.interprocess allocators with stl containers and map all in a fixed address in all processes.
Thanks for your reply. But while trying to do this, is there a guarantee that 1. the mapping will succeed (I am guessing not.)? 2. even if it succeeds, the mapped address range will *not* be already in use by the process? I am guessing some form of pre-reserving the VM address space range may be necessary - perhaps done during compilation or linking the programs concerned. Regards, Vishnu
Vishnu M Menon wrote:
Thanks for your reply.
But while trying to do this, is there a guarantee that
1. the mapping will succeed (I am guessing not.)?
No.
2. even if it succeeds, the mapped address range will *not* be already in use by the process?
If it's already used by the process, you won't be able to map it.
I am guessing some form of pre-reserving the VM address space range may be necessary - perhaps done during compilation or linking the programs concerned.
I can't help you much here, but I guess that you could use the linker file to reserve some virtual memory of your process that *maybe* could be used for this mapping. But I'm just guessing. Regards, Ion
Thanks, Ion. Regards, Vishnu
participants (3)
-
Ion Gaztañaga -
Phil Endecott -
Vishnu M Menon