boost::bimap and boost::interprocess
I've been trying to get boost::bimap to work in a boost::interprocess::managed_mapped_file. I've attached two small programs. Both compile with g++ 4.7. One (multiindex.c++) puts a multi_index into the managed_mapped_file. On the first run, it creates the data structure puts some stuff in it, then reopens the data structure and outputs the stuff. On the second run, it does the same thing, but it uses the data stored in the mapped file. The other program (bimap.c++) does exactly the same thing, but when run the second time it crashes. My guess is because bimap isn't quite interprocess compatible---that is, it isn't using the provided allocator for EVERYTHING. Compiled with: g++ -o multiindex multiindex.c++ -lpthread and g++ -g -o bimap bimap.c++ -lpthread Any suggestions? Any chance of bimap being made interprocess compatible? Thanks! Joel
Hi Joel, On Thu, Jan 24, 2013 at 10:54 PM, Joel Young <jdy@cryregarder.com> wrote:
I've been trying to get boost::bimap to work in a boost::interprocess::managed_mapped_file.
The other program (bimap.c++) does exactly the same thing, but when run the second time it crashes. My guess is because bimap isn't quite interprocess compatible---that is, it isn't using the provided allocator for EVERYTHING.
That is not the problem in this case, Bimap is just given your allocator to MultiIndex. The issue is that the map views (left, right and relation set) are initialized with a reference to the multiindex core in construction time... when interprocess read it from memory the second time this references are garbage. A direct solution will be to use interprocess offset_ptr, but that will have a performance hit so I will have to rethink how the views are accessing the core, probably using CRTP.
Any suggestions? Any chance of bimap being made interprocess compatible?
Totally, but I am right now quite deep in a complete rewrite of the lib to improve compilation times and error messages (that because of the use of the internal ContainerAdaptor, that it is being eliminated, were unreadable), and to have a better base to add the new C++11 goodies. I will like to focus on this first, and I will do the changes that are needed to make the lib work with Interprocess allocators in the meanwhile. Could you issue a ticket so we do not forget? Thanks for the report! Sorry it is not currently working with interprocess :( Best regards Matias
On Friday 25 January 2013 11:20:48 Matias Capeletto wrote:
Hi Joel,
On Thu, Jan 24, 2013 at 10:54 PM, Joel Young <jdy@cryregarder.com> wrote:
I've been trying to get boost::bimap to work in a boost::interprocess::managed_mapped_file.
The other program (bimap.c++) does exactly the same thing, but when run the second time it crashes. My guess is because bimap isn't quite interprocess compatible---that is, it isn't using the provided allocator for EVERYTHING.
That is not the problem in this case, Bimap is just given your allocator to MultiIndex. The issue is that the map views (left, right and relation set) are initialized with a reference to the multiindex core in construction time... when interprocess read it from memory the second time this references are garbage. A direct solution will be to use interprocess offset_ptr, but that will have a performance hit so I will have to rethink how the views are accessing the core, probably using CRTP.
Is it possible to port both Boost.MultiIndex and Boost.Bimap to Boost.Intrusive? The latter is capable of being process-independent (this feature is used in Boost.Interprocess). I guess this would also simplify Boost.MultiIndex significantly.
On Fri, Jan 25, 2013 at 11:37 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Is it possible to port both Boost.MultiIndex and Boost.Bimap to Boost.Intrusive? The latter is capable of being process-independent (this feature is used in Boost.Interprocess). I guess this would also simplify Boost.MultiIndex significantly.
Boost.MultiIndex already works with Boost.Interprocess with out problem. Boost.Bimap is not failing because of a limitation of Boost.MultiIndex but just because of how views are maintained right now that has nothing to do with the internal data structure. So going to Boost.Intrusive, although could simplify things inside MultiIndex will not help me here. I will change how I am referencing the core from the views when I finish the update and this problem will be gone. Best Matias
Matias Capeletto <matias.capeletto <at> gmail.com> writes:
Could you issue a ticket so we do not forget?
Matias, I posted a ticket in trac: https://svn.boost.org/trac/boost/ticket/7927 Thanks! Joel
On Fri, Jan 25, 2013 at 5:39 PM, Joel Young <jdy@cryregarder.com> wrote:
Matias Capeletto <matias.capeletto <at> gmail.com> writes:
Could you issue a ticket so we do not forget?
I posted a ticket in trac: https://svn.boost.org/trac/boost/ticket/7927
Thanks, I hope we can make it work soon. Best Matias
participants (3)
-
Andrey Semashev -
Joel Young -
Matias Capeletto