[Bug c++/21251] Placement into shared memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC||jackie.rosen at hushmail dot com --- Comment #16 from Jackie Rosen jackie.rosen at hushmail dot com --- *** 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.
[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 #15 from pinskia at gcc dot gnu dot org 2006-05-03 04:03 --- (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 suggestions? 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. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251
[Bug c++/21251] Placement into shared memory
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-22 20:44 --- 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. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED 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] Placement into shared memory
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-16 02:07 --- 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++). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement 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 pinskia at gcc dot gnu dot org 2005-04-27 14:03 --- 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. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords|wrong-code | Resolution||INVALID Version|3.4.3 |unknown 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 pcarlini at suse dot de 2005-04-27 15:01 --- (POD (Plain Old Data) is a technical term, defined in the standard, basically something you can copy bit by bit, via memcpy) -- 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
