Re: [Boost-users] Sharing a complex object between two processes: Suggestions needed

Subject: Re: [Boost-users] Sharing a complex object between two processes: Suggestions needed
From: Travis Gockel (travis_at_[hidden])
Date: 2011-07-15 18:55:39

On Wed, Jul 13, 2011 at 1:05 PM, Nathan Lewis <
nathanlewissubscription_at_[hidden]> wrote:

> Yes this was not my idea. However the back end devices are low level
> devices
> without Java sdks. I have taken over a project whereby they were using
> Java, JNI
> & C++ which apparently isn't working out so well. I was asked to create a
> prototype using c++ instead.
>
> Any thoughts on my actual question though?
>
>
>
>
>
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

If I was going to go with a C++ shared memory situation, I would start with
a shared memory region and use the library to allocate memory within that
mapped region.  Check out segment_manager and any_interprocess_allocator:
they would be extremely useful if you take this route (
http://www.boost.org/doc/libs/1_47_0/doc/html/interprocess/allocators_containers.html).
 You'll have to be *extremely* careful that all of your containers and all
of your objects use the instanced allocators.  If they don't and you end up
with a default allocator for some shared object, you will get a segmentation
fault in the best case and inconsistent data in the worst.  It might not be
possible to do if you don't have control over your generator (since you'll
have to change the Allocator typename in all the container types).

Personally, I would go with the Boost.Asio library and transfer data between
processes explicitly over a named pipe (Boost.Serialization or do it with
JSON).  This way, you won't get any funky
my-memory-was-changed-by-another-process action, which will make debugging a
million times easier.

The first option is going to be *way* easier to create if you can make your
code generator do it for you, but you have to be *extremely* careful about
your type definitions.  The second option might a little tedious for some of
the serialization, but should be easier to debug.

-- 
- Travis Gockel