[Bug c++/21251] Placement into shared memory
--- Comment #14 from mronell at alumni dot upenn dot edu 2006-05-03 02:39 --- 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 suggestions? 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 context switches. Thanks Marc -- mronell at alumni dot upenn dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
--- Comment #11 from mronell at alumni dot upenn dot edu 2005-11-16 02:01 --- 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 independent processes? Please remove the added dependence on 16612. Maybe the component should also be switched to c++? -- mronell at alumni dot upenn dot edu changed: What|Removed |Added BugsThisDependsOn|16612 | Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] New: Placement into shared memory
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? -- Summary: Placement into shared memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mronell at alumni dot upenn dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
-- What|Removed |Added GCC build triplet||i686-pc-linux-gnu GCC host triplet||i686-pc-linux-gnu GCC target triplet||i686-pc-linux-gnu Keywords||wrong-code Version|unknown |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
--- Additional Comments From mronell at alumni dot upenn dot edu 2005-04-27 14:56 --- 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. Thank you. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
--- Additional Comments From mronell at alumni dot upenn dot edu 2005-04-28 01:32 --- "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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug libstdc++/21251] Placement into shared memory
--- Additional Comments From mronell at alumni dot upenn dot edu 2005-05-02 16:49 --- 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 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 not understand. I am probably missing something obvious. Thank you, Marc -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
