I would like to use placement to instantiate a C++ object into a
shared memory segment and access that object from a second process.
When I test with an integer, the integer is accessible from the second
process. But when I instantiate a C++ class object, it seems a memory
pointer, which is local within the first process, is placed in memory.
The place object is fully accessible and usable in the first process.
I am guessing that the pointer points to the class definition within a
table local to that first process. Unfortunately, that table, which
does not seem to exist at the same address in the second process,
causes the second process to Seg fault when it attempts to access the
object instantiated in shared memory.
What is the current correct approach to instantiating objects in
shared memory so that multiple processes can access the C++ objects?
Are you talking about the vtable being at two different locations, well there is no way since the struct is
a non-POD which means it cannot do many things with.
If you want to share data, try with a POD instead.
I believe that the pointer points to a component within the vtable,
but I do not want to jump to that conclusion. When the object is
instantiated in shared memory, the first element seems to be a pointer
to something, probably the vtable, followed by what appears to be
object field values.
What does 'POD' stand for? I am not great with acronyms.
(POD ("Plain Old Data") is a technical term, defined in the standard, basically
something you can copy bit by bit, via memcpy)
"Plain Old Data" unfortunately is not a good solution in my case. I maintain
http://allocator.sourceforge.net which provides an open-source shared memory
allocator for the C++ Standard Template Library. This allocator has worked
with earlier versions of gcc/g++, but it depends on being able to instantiate
objects successfully in shared memory allowing multiple processes to access
the same objects. Localized vtable pointers would cause problems.
I have a new version of the allocator revised based on Knuth's Dynamic Memory
Storage algorithm from his Vol. 1. Its similar to Doug Lea's malloc.
However, as before, my approach depends on being able to place and share C++
objects through shared memory. Its that still possible?
Am I missing some esoteric compiler flags? Is this a bug or future feature request?
Thanks for your suggestions and input.
(In reply to comment #4)
> However, as before, my approach depends on being able to place and share C++
> objects through shared memory. Its that still possible?
> Am I missing some esoteric compiler flags? Is this a bug or future feature request?
No it is not possible. Now if you convince the standards committe that this is really should be possible,
then we will implement their recommendation but as of now, there is no way sorry.
> This allocator has worked
> with earlier versions of gcc/g++, but it depends on being able to instantiate
> objects successfully in shared memory allowing multiple processes to access
> the same objects.
What versions? I really doubt that it worked at all as vtable implementation has only changed on what
is the layout of the vtable.
> "Plain Old Data" unfortunately is not a good solution in my case. I maintain
> http://allocator.sourceforge.net which provides an open-source shared memory
> allocator for the C++ Standard Template Library.
Hmm, there allocators have specific requirements in C++.
Apologies for my persistence, but the following is still not clear to
me. Given the last reply to this concern, I now understand:
1. Placement into shared memory is not possible. If processes 1
instantiates objects into shared memory, these instantiated
objects can not necessarily be accessed by process 2 because the
vtable class definitions will not necessarily be at the same
address in both processes.
So given the assumption above, is a share memory allocator for the
Standard Template Library (STL) containers still possible? For
example, let process 1 create a vector<T,A> my_vect where A is a
working shared memory allocator and T is a valid class definition.
The allocator A, is assumed to correctly allocate and recycle memory
from an validly open shared memory segment. After process 1 defines
and populates my_vect with objects of type T, let process 2 similarly
define a vector using its own allocator A, defined the same as in
process 1. The allocator, A, in process 2 accesses the shared memory
segment in exactly the same way as in process 1. The address space of
the shared memory segment is mapped to the same virtual address space
in both processes. If the objects in the vector which were
instantiated by process 1 all point to process 1's vtable, won't
process 2 have trouble accessing the objects created by process 1
because process 2 may again have its vtable classes defined at
different memory addresses? How can process 2 make use of the objects
mapped into shared memory by process 1? Is a shared memory allocator
for the STL possible given that object placement in shared memory is
not possible? What is the difference between the two concepts and why
does one work (shared memory allocator) and one not work (placement)?
Can you point me to a reference which explains this concept as I do
I am probably missing something obvious.
Marc, we are talking about two completely different issues. Indeed, it's
*perfectly* possible using a shared-memory allocator with the STL containers.
In fact, we are in the process of providing an allocator of that type as part
of our library, just wait a bit more. OK?
This is a higher-priority enhancement request. We need a shared_memory
allocator, a lot of people want it, it would be cool and useful, etc.
The one in 16612 is not going to work. We don't and can't get assignment, and
the design is weak.
This cripples virtual inheritance for fine-grain parallel processing. There should at least be a compiler option for process-independent referencing, because admittedly, this would slow down dereferencing. Or maybe a operator new placement variant that specifies process-independent referencing. I can see that either way, it would cause major ripple effects. Maybe that's why I don't see any action on this item since May.
I am making this comment because I think it is a very important enhancement to make as soon as possible, as processors go multi-core. I have also read that the other signicifant c++ compiler uses process independent referencing.
To be sure we don't confuse two issues here (see also my #7), all the containers
are already able to use shared memory allocators such as libmm:
(via a very lightweight wrapper). This is even true for basic_string if config
with --fully-dynamic-string, and certainly for ext/vstring (or basic_string in
v7-branch). Another thing is the first issue in this PR, i.e., using a placement
new in shared memory, the last comment #9 if I understand well, things like
that. Maybe it would be better separate the two issues in separate PRs.
If placement using new into shared memory allows process independent memory referencing, other software tools (including allocators) can be developed.
This request asks, can placement into shared memory be provided for
Please remove the added dependence on 16612. Maybe the component should
also be switched to c++?
This almost need to go to the standards committee for how to deal with this (and maybe instead the IA64 ABI mailing list as we just follow that ABI for C++).
There is no way non PODs will ever work with shared memory. This is why they are called non-PODs and they never should be shared outside of the program. In fact non-PODs cannot be passed via var-args or even look at offsetof for each of the fields.
It seems to me an approach using thunks, or pass by name, or a similar
approach should work. Each process can evaluate the object in shared
memory with reference to the local virtual table to gain access to the
specified C++ type and its methods.
I imagine when it worked before under gcc, it was because the gcc compiler
had a better implementation of thunks.
I would like to see if Stroustrup could suggest a better solution? Have
you tried contacting some of that caliber in compiler design for
There may also be computer engineering hardware approaches which could
be faster than software. Something like a set of base/limit registers
sitting on the memory bus which are swapped in and out during process
(In reply to comment #14)
> I would like to see if Stroustrup could suggest a better solution? Have
> you tried contacting some of that caliber in compiler design for
Why don't you write to comp.lang.c++?
This is not the correct form to ask about the C++ standard or any new features with C++.
Also thunks have nothing to do with the problem here.
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.