MLM Veraart (Veraart++at++fel.tno.nl)
Thu, 24 Jun 1999 14:43:21 +0200
You can take a look at the following functions
shm_open();
mmap();
munmap();
close();
shm_unlink();
With this you can create memory mapped 'files'.
Create them on a local drive (/tmp/).
I have used them to pass data to unrelated processes.
You attach to a shared memeory by using its name.
You can put at the start of the shared memory the address that is
used in the process that created the shared region and then try
to use this address in a second call to mmap to use the same
address, use munmap() inbetween the calls to mmap.
Mario
Pete Willemsen wrote:
>
> Hi.
>
> We used something like this in a simulator we developed.
>
> For a quick summary, we basically overloaded the "new" and "delete"
> operators in a special class that we called SharedMemoryObject. Any C++
> class that we needed to share between processes was derived from the
> SharedMemoryObject class. The SharedMemoryObject class used our own
> shared memory allocation scheme (using SYSV shared memory) to allocate
> chunks of memory from a shared memory segment.
>
> There are a few tricky issues to deal with when you do something like
> this.
>
> 1) The shared memory that we created had to be directly mapped into each
> process in exactly the same virtual address space. This is necessary,
> especially if you use virtual functions because the virtual table and
> related pointers within will point to areas in shared memory. If this
> is not done, access to virtual member functions can cause strange
> segmentation violations that (in some cases) can be hard to debug. This
> can be tricky when using programs that link with things of different
> sizes. I came up with a "pre-run" test that would tell me what address
> locations were available to use and then I took the largest of these and
> used that as an argument to the simulator.
>
> 2) If a shared memory object allocates objects of its own, those objects
> will probably need to be made shared memory objects so the data and
> virtual pointers are still accessible.
>
> 3) This may not be portable to all systems, although we successfully ran
> this simulator on IRIX and Linux based systems.
>
> If you (or anyone else) is interested in more detail about this, I'll
> gladly send some code and more explanation, if necessary.
>
> Pete
>
> "Arnott, Shane D" wrote:
> >
> > Hi,
> >
> > I'm trying to find a nice way to share memory between two unrelated (read no
> > fork no sproc etc) processes.
> >
> > I have a Java UI front end that has a C++ layer underneath through JNI which
> > I want to talk to my C++ Vega/Performer app.
> >
> > The vgMem functions only help with related processes, so they are out.
> >
> > I've looked at pfDataPool but that doesn't seem suited to C++ with the only
> > memory allocation call being:
> >
> > vol void * pfDataPool::alloc(size_t...)
> >
> > It seems I have no way of doing a new on my C++ objects for both processes
> > to share.
> >
> > Does anybody have any other ways of cleanly sharing memory across unrelated
> > processes, especially one suited for C++.
> >
> > Thanks in advance.
> > ___________
> > Shane Arnott
> > Boeing Australia Limited * 363 Adelaide St * Brisbane * QLD 4000
> > Communications & Battle Management Systems * Systems Analysis Lab
> > Email: Shane.D.Arnott++at++Boeing.com * Ph: +61 7 3306 3320
> >
> Pete
> ----------------------------------------------
> Pete Willemsen Department of Comp. Sci.
> willemsn++at++cs.uiowa.edu University of Iowa
> ----------------------------------------------
This archive was generated by hypermail 2.0b2 on Thu Jun 24 1999 - 05:42:12 PDT