- Boost-users - lists.preview.boost.org

Forthcoming Boost.Fiber review
by Nat Goodspeed 28 Jan '14

28 Jan '14

Hi all, The review of Boost.Fiber by Oliver Kowalke is scheduled from Monday, January 6th to January 12th. ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiberinternally uses coroutines from Boost.Coroutine <http://ok73.funpic.de/boost/libs/coroutine/index.html>; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://ok73.funpic.de/boost/libs/fiber/doc/html/index.html<http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/> git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip<http://ok73.ok.funpic.de/boost.coroutine.zip> --------------------------------------------------- Naturally, you need not wait until the review formally opens to start reviewing the Fiber library. Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager ------------------------------

7 25

making a geometry half closed
by Sean Farrow 27 Jan '14

27 Jan '14

Hi, >From what I understand any boost geometry is fully closed. Is there a way of making a geometry half closed, such that the bottom row is not included? I'm needing to do this with a Box2D$Values. Any help appreciated. Cheers Sean.

6 8

[Geometry] Issues when registering a windows point type
by Sean Farrow 26 Jan '14

26 Jan '14

Hi, I'm having an Issue when trying to register a windows POINT type. I'm registering the Point structure from windef.h as follows: BOOST_GEOMETRY_REGISTER_POINT_2D(POINT, LONG, boost::geometry::cs::cartesian, x, y); I'm getting the following in my build log: 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2870: 'boost' : a namespace definition must appear either at file scope or immediately within another namespace definition 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2913: explicit specialization; 'boost::geometry::traits::tag' is not a specialization of a class template 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2059: syntax error : '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '{' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2447: '{' : missing function header (old-style formal list?) 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2913: explicit specialization; 'boost::geometry::traits::dimension' is not a specialization of a class template 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2059: syntax error : '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C3083: 'mpl': the symbol to the left of a '::' must be a type 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2039: 'int_' : is not a member of 'boost' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2913: explicit specialization; 'boost::geometry::traits::coordinate_type' is not a specialization of a class template 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2059: syntax error : '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2913: explicit specialization; 'boost::geometry::coordinate_system' is not a specialization of a class template 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2059: syntax error : '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C3083: 'cs': the symbol to the left of a '::' must be a type 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2039: 'cartesian' : is not a member of 'boost::geometry' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2143: syntax error : missing ';' before '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2913: explicit specialization; 'boost::access' is not a specialization of a class template 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2059: syntax error : '<' 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): error C2267: 'set' : static functions with block scope are illegal 1>c:\work\pantheon studios\o2\disesupport\supportfunctions.cpp(37): fatal error C1903: unable to recover from previous error(s); stopping compilation I'd rather not have to define my own point structure if at all possible! Any help appreciated to solve this. Cheers Sean.

2 2

Help compiling/linking boost example
by zaphod742 . 25 Jan '14

25 Jan '14

I installed boost-all-dev using apt-get on Ubuntu. I am trying to compile this example program of sync_client.cpp http://www.boost.org/doc/libs/1_45_0/doc/html/boost_asio/example/http/clien… I get this error .. $ sudo g++ sync_client.cpp -I usr/local/include/boost -L /usr/local/lib /tmp/ccaVkCWp.o: In function `__static_initialization_and_destruction_0(int, int)': sync_client.cpp:(.text+0xd61): undefined reference to `boost::system::generic_category()' sync_client.cpp:(.text+0xd6d): undefined reference to `boost::system::generic_category()' sync_client.cpp:(.text+0xd79): undefined reference to `boost::system::system_category()' /tmp/ccaVkCWp.o: In function `boost::system::error_code::error_code()': sync_client.cpp:(.text._ZN5boost6system10error_codeC2Ev[_ZN5boost6system10error_codeC5Ev]+0x17): undefined reference to `boost::system::system_category()' /tmp/ccaVkCWp.o: In function `boost::asio::error::get_system_category()': sync_client.cpp:(.text._ZN5boost4asio5error19get_system_categoryEv[boost::asio::error::get_system_category()]+0x5): undefined reference to `boost::system::system_category()' /tmp/ccaVkCWp.o: In function `boost::asio::detail::posix_tss_ptr_create(unsigned int&)': sync_client.cpp:(.text._ZN5boost4asio6detail20posix_tss_ptr_createERj[boost::asio::detail::posix_tss_ptr_create(unsigned int&)]+0x19): undefined reference to `pthread_key_create' /tmp/ccaVkCWp.o: In function `boost::asio::detail::posix_thread::~posix_thread()': sync_client.cpp:(.text._ZN5boost4asio6detail12posix_threadD2Ev[_ZN5boost4asio6detail12posix_threadD5Ev]+0x26): undefined reference to `pthread_detach' /tmp/ccaVkCWp.o: In function `boost::asio::detail::posix_thread::join()': sync_client.cpp:(.text._ZN5boost4asio6detail12posix_thread4joinEv[boost::asio::detail::posix_thread::join()]+0x2b): undefined reference to `pthread_join' /tmp/ccaVkCWp.o: In function `boost::asio::detail::posix_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::task_io_service>::context>::~posix_tss_ptr()': sync_client.cpp:(.text._ZN5boost4asio6detail13posix_tss_ptrINS1_10call_stackINS1_15task_io_serviceEE7contextEED2Ev[_ZN5boost4asio6detail13posix_tss_ptrINS1_10call_stackINS1_15task_io_serviceEE7contextEED5Ev]+0x15): undefined reference to `pthread_key_delete' /tmp/ccaVkCWp.o: In function `boost::asio::detail::posix_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::strand_service::strand_impl>::context>::~posix_tss_ptr()': sync_client.cpp:(.text._ZN5boost4asio6detail13posix_tss_ptrINS1_10call_stackINS1_14strand_service11strand_implEE7contextEED2Ev[_ZN5boost4asio6detail13posix_tss_ptrINS1_10call_stackINS1_14strand_service11strand_implEE7contextEED5Ev]+0x15): undefined reference to `pthread_key_delete' collect2: ld returned 1 exit status How can I solve this error?

1 0

Fwd: [boost] Boost.Fiber review January 6-15
by Nat Goodspeed 23 Jan '14

23 Jan '14

SUMMARY The review of the proposed Boost.Fiber library ended on January 15, 2014. The verdict is: not in its present form. The lively discussions during the course of the review indicate considerable interest in this library, however, and every submitted review can be read as: perhaps, if certain changes are made. This produced a long list of suggestions, which constitutes the bulk of this report. On behalf of the Boost community, I would like to commend Oliver Kowalke for the work he has put into the Fiber library so far. I encourage him to continue to evolve this library and to bring it back for a mini-review. Rather than considering the subject library as a whole, a Boost mini-review zooms in on particular issues. That seems an appropriate tool to use for further evaluation of the Fiber library -- always subject, of course, to the approval of the Review Wizards. I received seven formal votes, abbreviated here: Niall Douglas: YES, IF Eugene Yakubovich: YES, AND Antony Polukhin: YES, IF Vicente J. Botet Escriba: NO, UNTIL Agustín K-ballo Bergé: NO, IN CURRENT STATE Hartmut Kaiser: NO, IN CURRENT FORM Thomas Heller: NO, IN CURRENT FORM I thank each of these reviewers, and indeed everyone who investigated the Fiber library and participated in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. >From the long list of suggestions, a few key themes emerged. PERFORMANCE Many respondents requested performance tests (specifics below). There were a number of suggestions about possible performance pitfalls in the current implementation, such as use of STL containers (with consequent heap allocations) and locks for thread safety. Several people suggested implementing performance tests *before* starting any such optimizations, which seems like sensible advice. Niall Douglas pointed out that picking some fixed number of fibers is less interesting than showing how resource consumption rises with the number of fibers: "I think it isn't unreasonable for a library to enter Boost if it has good performance *scaling* to load (e.g. O(log N)), even if performance in the absolute or comparative-to-near-alternatives sense is not great. "Absolute performance can always be incrementally improved later, whereas poor performance scaling to load usually means the design is wrong and you're going to need a whole new library with new API. "This is why I really wanted to see performance scaling graphs. If they show O(N log N) or worse, then the design is deeply flawed and the library must not enter Boost. Until we have such a graph, we can't know as there is no substitute for empirical testing." Given the truth of that last observation, I have recast certain suggested optimizations as requests for measured performance cost. Performance requests include: - empty function (create, schedule, execute, delete one fiber) - same with one yield - overhead of using a future object - tests as described in [1]; such tests should allow comparing with TBB, qthreads, openmp, HPX - construct and join a single fiber vs. construct and join a single thread (empty function) - construct and join several fibers vs. construct and join several threads (empty function) - construct and detach a single fiber vs. construct and detach a single thread (empty function) - cost of STL containers (std::vector, std::map, std::deque) - cost of fiber interruption support (same as next bullet?) - cost of thread safety: intra-thread fibers vs. inter-thread fibers - cost of round_robin_ws vs. round_robin scheduler - cost of building on Coroutine vs. building on Context Once Fiber performance tests are available, I trust the community will assist Oliver in running them on systems otherwise unavailable to him. There was some disagreement on whether it is essential for the Fiber library to attain a certain level of performance before it should be accepted. Respondents fall into two broad camps. Some see fibers as lightweight threads (without the overhead of kernel context switching). They assert that since the API is that of std::thread, the only reason to accept a separate library would be astounding performance. They note that on some hardware it is already plausible to run hundreds of thousands of concurrent std::threads. Others see fibers as a tool for organizing code based around asynchronous operations (rather than chains of callbacks). They assert that for such purposes, eliminating the kernel from context switching is sufficient performance guarantee. I myself maintain that cooperative context switching provides important functionality you cannot reasonably get from std::thread. The Fiber library attempts to address both use cases. (It was suggested that if its primary target were code organization, perhaps it should be renamed something other than "Fiber.") In any case, the community clearly wants to see Fiber performance data. Some requested CPU cycles to eliminate clock speed differences, also memory consumption. ARMv7 data was requested for "extra bonus points." DOCUMENTATION Many respondents requested additional documentation, or clarifications. Requests include: - Rationale page explaining what's there, what's not and why. Explain distinction between Coroutine library and Fiber library. If certain Fiber functionality is intended to support yet another library (rather than being complete in itself), call out what would need to be added. - A section on how to install and run the tests and examples. The need to embed in a Boost tree is implied but not stated. Mention the need to build the library and link with it. - Explain synchronization between fibers on different threads. Must the code take more care with this than with synchronizing fibers on the same thread? - Clarify that an exception raised by a fiber function calls std::terminate(), as with std::thread, rather than being consumed. - More clearly explain migrating a fiber from one scheduler to another. - Document async() in a way compatible with the C++ standard. - Clarify thread-local effect of set_scheduling_algorithm(). There was a request to put this function in a this_thread nested namespace to further clarify. - Move algorithm class documentation to "Extension" or "Customization" section. Clarify that it's not part of the baseline library functionality, but a customization point. - Document fiber::id. - Better document promise/future for void and R& (per C++ standard). - Document thread safety of each support class (or method, if it varies by method). - Document complexity guarantees per API. - Document exception safety per API. - Document supported architectures (perhaps link to Coroutine library's list); state minimum compiler versions. - Document the get/set overloads of thread_affinity() and priority() separately. Perhaps rename setters to set_thread_affinity() and set_priority(). - Explain how portable is fiber priority, if it's specific to a scheduler. What does priority mean when you migrate a fiber from one thread (one scheduler instance) to another? - Document the library's ASIO support. Link to Coroutine's ASIO yield functionality; ensure that ASIO yield is adequately explained. In particular, distinguish it from this_fiber::yield. - Better explain (and/or comment) publish-subscribe example, also other existing examples. In addition to the documentation requests above, there were requests for additional examples: - Simple example of ASIO callback implementation vs. the same logic using Fiber's ASIO support, a la [4]. - Example of a fiber pool. - Example of an arbitrary thread B filling a future on which a fiber in thread A is waiting. - Example of an arbitrary thread B posting to an asio::io_service running fibers in thread A. - Either defend fibers::condition_variable from spurious wakeups in existing examples, OR document the stronger condition_variable guarantee. - Example of M:N threading with ASIO. That might involve either one io_service per CPU, with fiber migration; or a single io_service with run() calls from each CPU, grouping fibers for each CPU into strands. - Example of one thread with many fibers making service requests on a pool of worker threads performing blocking calls. - Example of using thread_specific_ptr to manage lifespan of user-specified scheduler. - Example of the owner of a fiber changing the fiber's thread affinity vs. the fiber itself. When would you use each tactic? - Load example programs into an Examples appendix so that Google searches can turn up library documentation. LIBRARY API - Four people overtly approved the close parallel with std::thread and its support classes. - Allocating a default scheduler object, rather than specifying a default template param, was praised. - Three people called out the set difference between Boost.Thread features and Fiber (e.g. future::get_exception_ptr()). One wants these implemented immediately; another says they can be added later; the third simply requests that they be documented, with rationale. - Two people frowned on introducing operator bool methods not found in std::thread or Boost.Thread. - C++11 support was mentioned, notably Boost macros such as BOOST_RV_REF and BOOST_EXPLICIT_OPERATOR_BOOL. Also mentioned were: C++11 idioms; C++11 std::thread patterns; move construction; initializer lists; rvalue this overloads; deleting operators. - The fiber constructor and async() should accept a move-only callable. - At least for a C++11 compiler, fiber constructor and async() should accept variadic parameters. These should support move-only types, like Boost.Thread. C++03 support for variadic parameters would be nice, but is less important. - Every API involving time point or duration should accept arbitrary clock types, immediately converting to a canonical duration type for internal use. - Queues should support value_pop() returning item by value. This supports an item type without a default constructor. - Nested scoped_lock typedef has been deprecated in thread library. Remove in Fiber library. - Align the return type of shared_future::get() with the standard. In general, ensure that parameter types and return types are aligned with the standard. - A couple of people were bothered by the use of types in the detail namespace as parameters or return values in the algorithm API. (I note, however, that extending e.g. Boost.Range can involve touching its detail namespace. A customization point for a library may be a bit of a gray area.) - There was a suggestion to rename algorithm to scheduler. In that case, presumably set_scheduling_algorithm() could be renamed set_scheduler(). - There was a request to rename round_robin_ws to round_robin_work_stealing. - A couple of people consider the algorithm API too monolithic, pointing to redundancies in the round_robin, round_robin_ws and asio round_robin implementations. They suggested teasing out distinct classes, so that (for instance) a user-coded scheduler might be able to override a single method to respect fiber priority. In fact Eugene Yakubovich offered to experiment with refactoring the algorithm class this way. - There was a request for set_scheduling_algorithm() to return the previous pointer. (It might be useful for the requester to explain the anticipated use case. An earlier iteration of set_scheduling_algorithm() did return the previous pointer; Oliver intentionally changed that behavior.) - fiber_group got one thumbs-up and two thumbs-down. Options: retain; improve to use move support rather than fiber*; discard. There is an opportunity to improve on thread_group; naturally there is risk in diverging from thread_group. - Request deferred futures for lazy evaluation. - There was a suggestion to introduce a global object to coordinate thread-specific fiber schedulers, in the hope that the global object could perform all relevant locking and the thread-specific fiber schedulers could themselves be thread-unsafe. - There was a request to unify steal_from() and migrate_to() into a single method. I infer that this is predicated on the previous suggestion. - Request future::then() et al, per [5]. (Someone please clarify the present status of N3784?) - Request enriched barrier support per [6] and [7]. (Someone please clarify the present status of N3817?) - There are two fiber properties specific to particular schedulers: thread_affinity (used only by round_robin_ws) and priority (as yet unused by any scheduler). What if a user-coded scheduler requires a fiber property that does not yet exist? Is there a general approach that could subsume the present support for thread_affinity and priority, in fiber and this_fiber? Could the initial values for such properties be passed as part of the fiber constructor's attributes parameter? - One use case was surfaced that may engage the previous bullet: the desire to associate a given fiber with any of a group of threads, such as the set of threads local to a NUMA domain or physical CPU. IMPLEMENTATION - Replace std::auto_ptr with boost::scoped_ptr. The former produces deprecation warnings on GCC. - Reduce redundancy between try_lock() and lock(). - boost::fibers::asio::detail::yield_handler::operator()() calls algorithm::spawn() before algorithm::run(). Does this allow the scheduler to choose the next fiber to run, e.g. a user-coded scheduler that respects fiber priority? - Add memory transaction support to spinlock a la [8]. - Intel TSX lock avoidance would be nice. LINKS [1] https://github.com/STEllAR-GROUP/hpx/tree/master/tests/performance [2] http://stellar.cct.lsu.edu/pubs/isc2012.pdf [3] http://stellar.cct.lsu.edu/pubs/scala13.pdf [4] https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AFIO_Do… [5] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3784.pdf [6] http://www.boost.org/doc/libs/1_55_0/doc/html/thread/synchronization.html#t… [7] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3817.html#barrier_… [8] https://github.com/BoostGSoC/boost.afio/blob/master/boost/afio/detail/ Nat Goodspeed Boost.Fiber Review Manager ________________________________

1 0

[Graph] initialize_vertex change vertex color (visitor)
by The Maschine 23 Jan '14

23 Jan '14

Hi all, I would like to build a visitor (for dikstra) with the initialise_vertex acting as 'colour map' modifier. I want to exclude some vertices from the search based on a condition. So I want to set some vertices 'black' in the init part of the algorithm. class dijkstra_2step : public boost::default_dijkstra_visitor { public: dijkstra_2step(std::vector<Weight> dists, double threshold): distances(dists), threshold(threshold) {} // THIS PART IS NOT CORRECT!!!! // void initialize_vertex(boost::graph_traits <unGraph>::vertex_descriptor u, const unGraph& g){ if( distances[u] > threshold ) color[u] = black; // ?????? } ////////// std::vector<Weight> distances; double threshold; }; Any help for the above visitor? How to I access the colour? I couldn't find something online. Thanks

3 12

[qi::phrase_parse] how to retain minus as string
by Uthpal Urubail 23 Jan '14

23 Jan '14

I am trying to store minus as the string in the key. I think its getting conflict with to(a-z) symbol key = +qi::char_(".a-zA-Z0-9") | qi::lexeme[('[' >> +qi::char_("@ + - * . ( , ) $ a-zA-Z0-9 ") >> ']')]; value = +qi::char_("a-zA-Z0-9") ; I have the string like below: std::string input = “[(@vala - @valb) * @valc]:real"; Can someone help me to resolve this? Regards, UJ

2 1

Build boost using CMake
by Chameera Wijebandara 23 Jan '14

23 Jan '14

Hi, I am new to the Boost. And I have to build Boost libraries with CMake. Any Suggestions? -- Thanks, Chameera

2 1

Server failing when BOOST_ASIO_ENABLE_HANDLER_TRACKING is active
by Gonzalo Garramuno 22 Jan '14

22 Jan '14

Trying to track down when the socket closes on my program, I turned on asio debugging. Server fails when BOOST_ASIO_ENABLE_HANDLER_TRACKING is active. Its stack trace is: g Scanning dependencies of target mrViewer [ 9%] Building CXX object mrViewer/src/CMakeFiles/mrViewer.dir/core/mrvServer.o Linking CXX executable ../../../bin/mrViewer [100%] Built target mrViewer # gga@gga-laptop1 /media/Linux/code/applications/mrViewer # mar ene 01 10:04 [8] $ mrViewer /media/Linux/movies/Tangled.mov [opengl] Using hardware shader profile: NVidia NV30 [opengl] mrViewer supports YUV images through shaders. [psql] Connected to database 'assets2d_development'. The code: boost::asio::io_service io_service; tcp::endpoint listen_endpoint(tcp::v4(), s->port); server rp(io_service, listen_endpoint, s->ui); io_service.run(); fails with: @asio|1357088683.200673|0|socket@0x7f303d8d2d00.close Got signal 11, faulty address is 0x1, from 0x4d222a [bt] Execution path: [bt] mrViewer(_ZN5boost4asio6detail15task_io_service16shutdown_serviceEv+0x3a) [0x4d222a] [bt] mrViewer(_ZN5boost4asio6detail15task_io_service16shutdown_serviceEv+0x3a) [0x4d222a] [bt] mrViewer() [0x4dd2c9] [bt] mrViewer(_ZN3mrv13server_threadEPKNS_10ServerDataE+0x408) [0x4e0e58] [bt] /usr/lib/libboost_thread.so.1.48.0(+0xdda9) [0x7f304e191da9] [bt] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f304f7f0e9a] [bt] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f304da1ccbd] without the #define the code works reliably except sometimes the socket closes unexpectedly.

4 5

Re: [Boost-users] Interprocess: rbtree_best_fit ABI change from 1.53 to 1.55 ?
by Arunski, Kevin 22 Jan '14

22 Jan '14

> El 22/01/2014 16:14, Arunski, Kevin escribió: > > Hello, I have been using a boost::interprocess::map stored in a > > managed mapped file segment, using the rb_best_fit allocation > > algorithm. > > > > I have observed that starting in boost 1.55, I cannot interoperate > > with instances of this allocator that were created by programs > > compiled by boost 1.53. > > > > It appears that the size of a boost::intrusive multiset object has > > changed, and this changes the representation of the rb_best_fit > > algorithm within the shared memory region. > > Sorry about that. That must be a bug. Can you tell me please the sizes > you get in both versions? Sure. In code compiled with boost 1.53, this type: boost::interprocess::rbtree_best_fit<boost::interprocess::null_mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0> has size = 56 member m_header.m_imultiset has size 32 In code compiled with boost 1.55: the same type has size = 72 member m_header.m_imultiset has size 48

2 1