- Boost-announce - lists.preview.boost.org

[TypeIndex 3.0] Review Manager's Report
by Niall Douglas 04 May '14

04 May '14

Dear Boost, The second round of peer review of proposed Boost.TypeIndex finished on Wed 30th, and here is the review manager's report. My thanks to the five reviewers who took the time and trouble to submit full reviews, plus to everyone else who commented. Votes regarding acceptance: 4 voted to accept TypeIndex into Boost immediately. 1 voted to accept into Boost with conditions. Overall: I recommend immediate acceptance into Boost. Conditions: 1. No one liked the present boost::typeind namespace, almost anything else would be better. I see the namespace has already changed in the develop branch to boost::typeindex, so I think this is already solved. Other common comments: * More than one reviewer mentioned how they liked the docs. * More than one reviewer expressed a desire for an ability to programmatically parse through type specifier strings. I agree with Antony that that is another library which isn't TypeIndex (something Boost.Spirit based which works directly with mangled symbol string representations, representing them as a partial AST - preferably also with a libclang compatible backend - would be great, but that is a totally different library and TypeIndex 3.x provides extensibility for such an additional function). * More than one reviewer sought some method of preventing link if you mix up incompatible uses of TypeIndex and/or with RTTI. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

[gsoc2014] This year's students announced
by Niall Douglas 22 Apr '14

22 Apr '14

Dear Boost, We are pleased to announce that the following eight students will be this year's Google Summer of Code for 2014: 1. Anton Bikineev Mentor: Christopher Kormanyos Topic:Boost.Math Generalized Hypergeometric Functions 2. Ian Forbes Mentor: Tim Blechmann Topic: Boost.Thread Scheduled Executors 3. Louis Dionne Mentor: Joel Falcou Topic: A C++11 template metaprogramming library 4. Mark Lingle Mentor: David Bellot Topic: Boost.uBlas: Optimization via Smart Templating and a Tree Optimizer class 5. Roshan Mentor: Kyle Lutz Topic: Expand and Improve Boost.Compute 6. Saksham Maheshwari Mentor: Stefan Seefeld Topic: Boost.XML - A Standard XML Library 7. Thaler Benedek Mentor: Vicente J. Botet Escriba Topic: Boost.Pipeline 8. Vinícius dos Santos Oliveira Mentor: Bjorn Reese Topic: HTTP server on Boost At US$5,000 funding per student, this represents an investment of US$40,000 into Boost by Google this year, for which we are extremely grateful. Our thanks to everyone in Google who makes this happen every year. With so few slots available from Google some very good candidates and proposals could not be selected, so if you were not selected this year, better luck next year (remember to come early!). Congratulations to the students who did make it, and our collective thanks go to the primary mentors above for taking the time this summer, as well to the secondary mentors not listed above as well as everyone who helped out with the proposal review and the ranking and voting this year. Niall & Boris --- Boost C++ Libraries Google Summer of Code 2014 admin https://svn.boost.org/trac/boost/wiki/SoC2014

1 0

Boost.Align review results
by Ahmed Charles 21 Apr '14

21 Apr '14

The review of the proposed Boost.Align library ended on April 20, 2014. The result is: Accepted with conditions. Glen and I would like to thank everyone for contributing to the review for Boost.Align. either with a review or comments in the discussions. The summary of formal votes is as follows (alphabetical order): Andrey Semashev - Yes (conditional) Antony Polukhin - Yes (conditional) Bjorn Reese - Yes Lars Viklund - Yes Michael Spencer - Yes For a total of 5 votes for acceptance and 0 votes for rejection. The conditional acceptance is based on the quality of documentation, as the feedback given on code and design has already been addressed. The conditions below are agreeable to the author: 1. QuickBook documentation should be used, following typical Boost documentation structure. 2. Additional examples should be used to make the understanding/use of the library easier. 3. Additional minor comments from the reviews should be addressed. I would like to thank Glen for making this an easy first review manager experience and I look forward to reviewing other libraries in the future.

1 0

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 20 Apr '14

20 Apr '14

Dear Boost, A second round of community review begins for proposed Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as it's my fault for starting another peer review straight after Boost.Align ends, however I was busy as Google Summer of Code admin until today, and I will be preparing to talk at C++ Now straight after this review ends. I hope that this doesn't affect the community's willingness to contribute to the review. Reminder of the report from the last TypeIndex v2.1 review: https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0 Reminder of the original peer review announcement: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Changes in TypeIndex v3.0 since v2.1 (from my own review of it): 1. Documentation is hugely improved over v2.1, lots of side by side examples illustrating the differences and similarities. 2. You can now create your own custom type indices using an extensible framework. 3. boost::typeind::type_info now exports raw_name() and pretty_name() to maximise MSVC-GCC compatibility, and to solve point 1 but not point 2 in the v2.1 report. 4. The undefined behaviour trick used in v2.1 has been replaced with a cast via the placeholder type boost::typeind::detail::ctti_data which can be viewed in https://github.com/apolukhin/type_index/blob/master/include/boost/type _index/ctti_type_index.hpp. There is an explanation in the comments there about this technique's compatibility with the C++ standard. 5. TypeIndex now defines everything in the boost::typeind namespace instead of the boost namespace. So: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks, Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

Boost.Align review begins today
by Ahmed Charles 12 Apr '14

12 Apr '14

Hi all, The review of Boost.Align by Glen Fernandes commences today, Friday, 11 April, and concludes Sunday, 20 April. Boost.Align provides: 1. Function align() to align a pointer, for implementations which do not provide C++11's std::align(). 2. Functions aligned_alloc() and aligned_free() for dynamic allocation with specified alignment. { For use in place of ::operator new() and ::operator delete(). } 3. Class template aligned_allocator as an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of std::allocator. } 4. Class template aligned_allocator_adaptor to turn any existing allocator into an alignment-aware allocator that also allows specifying a minimum alignment. { For use in place of any existing allocator type. } 5. Function is_aligned() to test the alignment of a pointer. Rationale: C++11 added the ability to specify increased alignment (over-alignment) for class types. Unfortunately, ::operator new allocation functions, new expressions, and the default allocator, std::allocator, do not support dynamic memory allocation of over-aligned data. Notes: This library also meets needs in existing Boost libraries. - Boost.Smart_Ptr has its own implementation of align(). - Boost.Interprocess and Boost.Log each have their own implementation of aligned_alloc() and aligned_free(). Source: doc: http://glenfe.github.io/align git: http://github.com/glenfe/align zip: http://github.com/glenfe/align/archive/master.zip 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? Ahmed Charles Review Manager

1 0

Boost.Align review announcement
by Ahmed Charles 28 Mar '14

28 Mar '14

Hi everyone, The review of Boost.Align by Glen Fernandes is scheduled from Friday, April 11th to April 20th. Source: http://github.com/glenfe/align Documentation: http://glenfe.github.io/align Description: This library provides function align for implementations which do not have the C++11 standard library align function available.It provides allocation functions aligned_alloc and aligned_free as their functionality is not yet available in the C++ standard library. They use platform specific functions, if available, or use standard library functions in conjunction with align.It provides C++ allocators, class templates aligned_allocator and aligned_allocator_adaptor, which respect alignment. The first uses aligned_alloc and aligned_free while the second uses the allocator in conjunction with align.It also provides function is_aligned to test the alignment of a pointer. Rationale: C++11 added the ability to specify increased alignment (over-alignment) for class types. Unfortunately, ::operator new allocation functions, new expressions, and the default allocator, std::allocator, do not support dynamic memory allocation of over-aligned data. The aligned_alloc function can be used in place of ::operator new to specify the alignment of the memory allocated.The aligned_allocator class template can be used in place of std::allocator as an alignment-aware default allocator.The aligned_allocator_adaptor class template can be used to adapt any allocator into an alignment-aware allocator. Notes: The functionality provided by this library addresses needs in existing Boost libraries as well. Boost.SmartPtr has its own implementation of align, and Boost.Log and Boost.Interprocess have their own implementations of aligned_alloc and aligned_free. Boost List Discussion: http://lists.boost.org/Archives/boost/2014/02/211723.php Review Manager: Ahmed Charles

1 0

[GSoC 14] Request community to rank proposals
by Niall Douglas 24 Mar '14

24 Mar '14

Dear Boost Community, The Google Summer of Code 2014 proposals for Boost are in, and we would deeply appreciate the community's help in ranking the proposals according to merit before the 1st of April. To vote, the process is easy: 1. Go to this page https://www.google-melange.com/gsoc/homepage/google/gsoc2014 and click the "Log in" button under Mentors and Administrators. 2. Now click "Create Profile" on the same page. Note that even if you registered last year, you must register again in 2014. Fill in the form. Note that after submitting it drops you at "Edit Profile", which is confusing. 3. Click "My Dashboard", then "Connect with organisations". 4. Choose "Boost C++ Libraries". 5. In the message box, write this: "I am a member of the Boost community and the email(s) I normally post to boost mailing lists with is <email>" filling in the email address(es) you normally use to post to boost mailing lists. This lets us verify that you are indeed a long standing member of the Boost community. 6. Once we approve your request, you will get an email with the subject "Welcome as organisation member". You can now return to the Dashboard on the GSoC website where there will be a new item "Proposals". 7. Work your way through as many of the 42 proposals as you can. You can score them using the stars at the bottom of each proposal page, taking care to read any comments by the mentors and students if present. PLEASE try to rank some of the lowest scored proposals, every year we get a lot of people who only rank the top five and don't bother with the rest. Try to score on the basis of (i) proposal quality and your best estimate of the student's capability (ii) if the student came early to the mailing lists to ask for help writing the proposal (the mentors who helped them with their proposals have usually indicated this in the private comments) (iii) usefulness/appropriateness of the feature or work being proposed. Remember a good GSoC is more about getting promising new engineers into Boost and C++ than necessarily getting code to pass Boost peer review in a single summer. 8. Optional: If a proposal looks especially great to you and you feel able to mentor a student this year, please slide the "wish to mentor" button. Just because a proposal already has willing mentors does NOT mean you should not add yourself - we have at least two mentors with many attached very highly ranked proposals and we really don't want to have to reject an outstanding proposal just because we can't find the mentors for it as no mentor can realistically mentor more than two projects simultaneously. As you know, Google Summer of Code is usually worth $35,000 - $50,000 to Boost each year, and a successful GSoC raises our visibility and reputation in the wider open source community. Our thanks to you in advance for taking the time to vote. Niall Douglas Boris Schäling --- Boost C++ Libraries Google Summer of Code 2014 admin https://svn.boost.org/trac/boost/wiki/SoC2014

1 0

NT² 3.0 and Boost.SIMD - Stable release
by Joel Falcou 15 Feb '14

15 Feb '14

The first stable release of the 3.x series of MetaScale’s open-source software is available: NT² 3.0. It also includes its spin-off project, Boost.SIMD (not yet a Boost library). Many Issues have been closed since last beta. The main focus of this release cycle was to fix performances issues and to stabilize some parts of the API. Next step will be to separate NT2 and Boost.SIMD into separate repositories, thus making one more step toward Boost.SIMD submission into review. [ http://www.metascale.org/nt%C2%B2-3-0-and-boost-simd ] *Changes & Bug Fixes:* - Major performance improvements in both libraries - Added experimental support for the HPX runtime for parallelization on shared memory systems - Optimizations of many elemental functions, in particuler log/ex, frexp/ldexp and cbrt - More advanced shuffle pattern recognition for SIMD - Fixed issues with Visual Studio 2013 - More functions are force-inlined to ensure good performance - New functions for conversion between types and mixing of vectors of different sizes - Demo applications usable as benchmarks - Better handling of errors when an unsupported function is called - New API for custom memory allocators Full changelog is available at https://github.com/MetaScale/nt2/releases/tag/3.0.0. *How to get it ?* - Source and binary packages can be downloaded here: http://nt2.metascale.org/downloads - The release is also available on Github : https://github.com/MetaScale/nt2/releases - The main master branch is still under development : https://github.com/MetaScale/nt2

1 0

Attn: We need GSoC 2014 mentors for Boost!
by Niall Douglas 08 Feb '14

08 Feb '14

Dear Boost community, We are now just five days away from the closing date for Google Summer of Code 2014 registration. Last year's GSoC was a huge success, with Google funding work on Boost to the tune of $35,000 and paying over $8,000 in costs for three representatives of Boost to attend the GSoC mentor's summit at Google HQ. As part of filling in our application for 2014, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2014. We do NOT want a repeat of 2012 when our application was rejected due to an insufficiently long list of prospective mentors and projects! At the time of writing, we have just *eight* prospective mentors, and we need more to be sure of being approved by Google! Therefore, if you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list at https://svn.boost.org/trac/boost/wiki/SoC2014. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org. Thank you in advance for your time. Niall Douglas (Boost Google Summer of Code admin) Boris Schäling (Boost Google Summer of Code backup admin)

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