Boost logo

Boost Users :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2020-02-14 04:24:44


On 30/01/2020 9:19, Gaier, Bjoern via Boost-users wrote:
> Hello Boost-Mailing-List,
>
> I have a question about the boost interprocess library - and I hope I
> can explain it correctly.
>
> I looked at the "Quick guide for the impatient" about the interprocess
> library - but I'm not sure if I can use this for our purpose.
>
> The main goal is to insert a STL vector (or different container) in a
> predefined portion of an already existing shared memory. The main
> problem is, that we cannot use the managed_shared_memory code from
> boost, because we rely on a different API to allocate the shared memory
> between Windows and other devices. Also the container should be placed
> at a fixed offset inside the created shared memory.
>
> I'm a complete newbie with boost and the interprocess library, that is
> why I'm not sure which interface I have to provide for the interprocess
> vector to be setup correctly. I hoped I could do something like:
>
> new (srh_mem_base + offset) boost::interprocess::vector<allocator>;
>
> I tried looking into the headers of the library to get an idea of that,
> but I honestly got lost.
>
> I'm really sorry if this a stupid or obvious question - and I thank for
> any help in advance!

Unfortunatelly does not going to work. A shared memory vector expects a
shared memory allocator that relies on the segment_manager class. That
class expects a managed shared memory (or mapped file) that resolves
allocation requests looking for free space in the managed shared memory
segment.

You would need to define a new allocator and managed shared memory (as
you need to handle the allocation requests from the vector) that
fulfills your needs. Not an easy task at all.

For fixed offsets, you'd better avoid Interprocess and use an array or
similar with no dynamic allocations.

Best,

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