I think what you are asking here is whether
the allocator can be used to allow two
separately created processes to share the
same memory space as opposed to having a
parent process fork off a child process and
then share a memory space with its child.
The provided example does the latter.
Currently, the allocator develops its shared
memory segment key, the identifier which
indicates which shared memory segment is used
with a call to the UNIX function, ftok. ftok
converts a pathname and a project identifier
to a System V IPC key (see man ftok). This
key is then used to generate or identify the
shared memory segments to access. The call
to ftok is located in the shared_memory.cc
file.
One problem which arises when creating an
object is deciding how to pass a parameter,
like a key which indicates which shared
memory block, to an object which is only
capable of accepting types, not values.
Here, the Pool_alloc<int> only takes a type,
int. There is no way to pass a shared memory
key parameter value.
Say I have two separate areas of shared
memory, Shared Memory segment A, and Shared
Memory segment B. Segment A is accessed
using key A and segment B is accessed using
key B. Either I need to pass new objects
which need to access the memory segments the
correct key, or I need to declared Segment A
to be of one memory type and Segment B to be
of another memory type and create my key
values based on the memory segment type
names. There are other solutions, but at the
moment, this one seems to have the most merit
to me.
I need to ask the C++ community if this issue
has already been addressed and whether a
generally accepted solution already exists.
If not, I will create the next generation of
the allocator to work based on this
principle, which will solve your issue.
Meanwhile, you can hack the shared_memory.cc
code to fix the key to be more static. Or,
hopefully, someone else will chime in with a
better solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Marc and Fred or anyone else,
My question is if this package can be used for sharing memory between none related processes?
I tried to write some test code, but it does not work, How does my second process can call Shared::allocate to attach the exisiting memory?
Thanks,
Jim
Does anybody can answer this question or give me an example?
Thanks,
Jim
I think what you are asking here is whether
the allocator can be used to allow two
separately created processes to share the
same memory space as opposed to having a
parent process fork off a child process and
then share a memory space with its child.
The provided example does the latter.
Currently, the allocator develops its shared
memory segment key, the identifier which
indicates which shared memory segment is used
with a call to the UNIX function, ftok. ftok
converts a pathname and a project identifier
to a System V IPC key (see man ftok). This
key is then used to generate or identify the
shared memory segments to access. The call
to ftok is located in the shared_memory.cc
file.
One problem which arises when creating an
object is deciding how to pass a parameter,
like a key which indicates which shared
memory block, to an object which is only
capable of accepting types, not values.
std::vector<int,
allocator_ns::Pool_alloc<int> > w;
Here, the Pool_alloc<int> only takes a type,
int. There is no way to pass a shared memory
key parameter value.
Say I have two separate areas of shared
memory, Shared Memory segment A, and Shared
Memory segment B. Segment A is accessed
using key A and segment B is accessed using
key B. Either I need to pass new objects
which need to access the memory segments the
correct key, or I need to declared Segment A
to be of one memory type and Segment B to be
of another memory type and create my key
values based on the memory segment type
names. There are other solutions, but at the
moment, this one seems to have the most merit
to me.
std::vector<int,allocator_ns::Pool_alloc<int,
allocator_ns::Pool_Type_A> > w;
std::vector<int,allocator_ns::Pool_alloc<int,
allocator_ns::Pool_Type_B> > w;
I need to ask the C++ community if this issue
has already been addressed and whether a
generally accepted solution already exists.
If not, I will create the next generation of
the allocator to work based on this
principle, which will solve your issue.
Meanwhile, you can hack the shared_memory.cc
code to fix the key to be more static. Or,
hopefully, someone else will chime in with a
better solution.