Boost logo

Boost Users :

From: Berenguer Blasi (bblasi_at_[hidden])
Date: 2006-07-15 04:16:34


Ion,

thank you for your reply.

As you suggested mmap returns a different address than the one specified,
behaving as a named_shared_object under the hood instead of a
fixed_named_shared_object.

I have used the MAP_FIXED flag for mmap with disastrous results (the man
pages already discourage you to use this flag). The computer hanged, very
strange behaviours, etc... It just forces a segment the size you want at the
address you specify overwriting anything in it's way. Lots of fun as you can
foresee...

So as I see it:

        - You cannot store raw pointers in a shared memory even if you use
fixed_named_shared_object. They all have to be offset_ptr always as it may
not map where you want.
        - Documentation under 'Using STL containers and mapping the memory at a
fixed address' should reflect this.

A possible workaround, as you suggested, would be to somehow write down the
address where the memory was mapped to so that other processes know about
it. IMHO this is a named_shared_object in the end, so why use
fixed_named_shared_object?

I think that due to the inner behavior of mmap as long as you are aware that
a fixed_named_shared_object is in fact an
OCCASIONALY_fixed_named_shared_object everything sould be alright. Notice
that the same binary run twice on the same box may map to a different
address each time which may or may not be the one specified! And even if it
returns false during creation of the segment you have already screwed your
box overwritting protected memory areas...

Do you agree or have I got the wrong end of the stick?

(I use Linux Fedora Core 5)


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