[Boost-bugs] [Boost C++ Libraries] #10581: Conflict when using boost::interprocess objects when linking to 2 different boost versions

Subject: [Boost-bugs] [Boost C++ Libraries] #10581: Conflict when using boost::interprocess objects when linking to 2 different boost versions
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-10-02 07:27:54

#10581: Conflict when using boost::interprocess  objects when linking to 2
different boost versions
------------------------------+--------------------------
 Reporter:  Yochai Timmer     |      Owner:  igaztanaga
     Type:  Bugs              |     Status:  new
Milestone:  To Be Determined  |  Component:  interprocess
  Version:  Boost 1.55.0      |   Severity:  Problem
 Keywords:                    |
------------------------------+--------------------------
 '''Introduction''':
 Boost interprocess directory and file naming has changed after boost 1.54.
 Intreprocess communication does not work between version greater than 1.54
 and lower than 1.54.
 Related bug report: https://svn.boost.org/trac/boost/ticket/9767


 '''The Scenario''':
 Compile a .dll that uses some shared memory object from the
 boost::interprocess library with version 1.55. (Think of this as an
 external 3rd party dll which you have no control over).
 Then make another project, using an older version of boost, lets say boost
 1.51.
 In the new project, open a shared memory object, then call a function from
 the dll that also opens a shared memory object.
 This should have opened 2 shared memory objects, one with the 1.55 version
 and one with the 1.51 version.

 The problem is that the second memory object will always fail (even if you
 change the order).

 '''The Problem''':
 Boost uses a singleton object to map the open interprocess memory objects.
 Because of the versions mismatch, the first shared memory object that is
 created, also creates the map (And with it the file naming convention).

 '''Solution''':
 The singleton '''should''' just map the items, but use the functions
 according to the calling binary and compiled version of the caller.

 '''Workaround''':
 I've just changed the names in the singleton object.
 I figured you can't have redundancy if it's incompatible, so lets have a
 separate memory mapping.
 In windows_intermodule_singleton.hpp changing the
 windows_semaphore_based_map named objects for the 1.55 version will keep
 the map separated.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10581>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.