Re: [Boost-users] [Interprocess] error_code_t = 9 (already_exists_error) while opening a fixed_managed_shared_memory

Subject: Re: [Boost-users] [Interprocess] error_code_t = 9 (already_exists_error) while opening a fixed_managed_shared_memory
From: Gaetan Gaumer (gaetan.gaumer_at_[hidden])
Date: 2011-05-20 04:15:52

Hello again,
For more information,  we're working on a Linux x64  (RHEL 5.4) with Boost 1.45
[...]
>> So I have two questions :
>> 1) Do you have an idea why the mmap function maps the segment at a
>> different address from the provided one, knowing that this address
>> is the one returned from code below on another process (so should be
>> valid) ?
>
> Every address can be different in each process. Shared memory, in some
> systems, shares address space with DLLs and other goodies. Depending on your
> memory map when you call mmap, the address chosen by each process might be
> different.

But for fixed_managed_shared_memory  the segment must be mapped at the
same address, isn't it ?
That's what is explained in the doc :
http://www.boost.org/doc/libs/1_46_0/doc/html/interprocess/managed_memory_segments.html
"The user can also map the managed shared memory in a fixed address.
This option is essential
when using using fixed_managed_shared_memory" (typo inside)

If two processes can't be sure to be able to map the segment at the same address
then fixed_managed_shared_memory seems to be useless.

>
>> 2) In the mapped_region constructor, when a non null address value is
>> given as a parameter, could we use the MAP_FIXED flag  to force
>> the mmap function to map the segment at the provided address ?
>
> That would break portable semantics, we want mapped_region to fail if the
> address was used, otherwise, you might be unmapping DLL code or any other
> previous mapping (mapped file, etc.) and bad things will happen. MAP_FIXED
> is IMHO usable only to map devices/video memory that you know exactly where
> they are placed in your system.

What I still don't understand is why sometimes that's work well and
sometimes it fails.
If the system consider that the memory address is used by another
process, then it should
fail every time ( and then fixed_managed_shared_memory should not be
unusable at all).

I'll further investigate the usecase which conduce to the error to see
if we're doing something wrong.

As we're working on Linux, do you think that using xsi_shared_memory
could help ?
Is there a fixed_managed_xsi_shared_memory ?

I think the last option is to switch to basic_managed_shared_memory
and work with offset pointers but
I dont't like this option especially knowing that
fixed_managed_shared_memory should work and meet our needs.

Thanks for you help,
Gaëtan