- Boost - lists.preview.boost.org

[release] Master Branch is closed for major code changes
by Marshall Clow 02 Nov '23

02 Nov '23

The master branch closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. The master branch will close for the 1.84.0 beta release next Wednesday As always, the calendar is available at: https://www.boost.org/development/ — The release managers

1 0

[Release] Boost 1.84.0 closing for major changes TOMORROW
by Marshall Clow 31 Oct '23

31 Oct '23

Release closed for major code changes. Still open for serious problem fixes and docs changes without release manager review. See: https://www.boost.org/development/index.html — Marshall

1 0

[scope] Looking for endorsements and review manager
by Andrey Semashev 31 Oct '23

31 Oct '23

Hi, This is a reminder that Boost.Scope is looking for endorsements and a review manager. Following is an excerpt from the previous announcement, describing the library. Boost.Scope is a small library implementing utilities defined in <experimental/scope> from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper. Compared to <experimental/scope>, some notable extensions are: * A new scope_final scope guard, which is a more lightweight alternative to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that allows to simplify scope guard declaration syntax. * Scope guards can be activated/deactivated multiple times. * Scope guards can be created inactive initially. * Scope guard factory functions, for compatibility with C++11. * Support for optional resource traits in unique_resource wrapper, which improves usage with resources having unallocated values. * unique_resource supports swapping. * unique_resource supports dereferencing for any resource types that support dereferencing, not only pointers. * More flexible constructors for unique_resource. The library requires C++11 at the minimum and will significantly benefit from C++17. Source: https://github.com/Lastique/scope Docs: https://lastique.github.io/scope/libs/scope/doc/html/index.html The library is tested in CI and used in production in one of my projects. Thanks.

5 14

Use of boost::anys::unique_any in place of boost::any
by Bhuyan, Jyotideep 23 Oct '23

23 Oct '23

Hello, As per documentation, Boost::Any is getting deprecated, and it was suggested to use boost::anys::unique_any. I am using boost::any and boost::any_cast heavily in my application code. I am looking for some sample code for best practices on how we can replace boost::any and boost::any_cast with boost::anys::unique_any. I am using VS2022, boost v1.83, and building the code with C++17. Best Regards, Jyotideep Bhuyan (he/him) Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. Confidential - Company Proprietary

1 0

[Looking for Feedback] - Fairness lib
by Federico Abrignani 22 Oct '23

22 Oct '23

Dear Boost Community, I am writing to seek feedback on a new C++ library that I have been developing (https://github.com/Sernior/fairness <https://github.com/Sernior/fairness>). This library, named "*Fairness*," is still a work in progress. Nonetheless, I believe that this is an opportune time to begin gathering feedback. *Fairness* is designed to provide fair synchronization primitives. While the standard C++ library offers various tools for managing concurrency, it does not provide mechanisms for handling fairness policies. To introduce the most fundamental component of my library, the "priority_mutex," I would like to share a simple example: /#include <thread>/ /#include <chrono>/ /#include <algorithm>/ /#include <BS_thread_pool.hpp>/ /#include <boost/fairness.hpp>/ / / /static boost::fairness::priority_mutex<4> pm;/ / / /static void busy_wait_nano(int64_t nanoseconds){/ /auto begin = std::chrono::steady_clock::now();/ /for(;std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::steady_clock::now() - begin).count() < nanoseconds;)/ / continue;/ /}/ / / /static void thread_function_nano(int p, int preCriticalTime, int postCriticalTime, int criticalTime){/ / busy_wait_nano(preCriticalTime);/ / pm.lock(p);/ / busy_wait_nano(criticalTime);/ / pm.unlock();/ / busy_wait_nano(postCriticalTime);/ /}/ / / /int main()/ /{/ / std::array<int, 8> prios {0, 2, 2, 1, 1, 3, 3, 0};/ / std::array<int, 8> preCT {2000, 1500, 2000, 3000, 1000, 500, 500, 2000};/ / std::array<int, 8> postCT {5000, 3000, 2000, 2500, 1000, 1500, 1500, 4500};/ / int criticalTime = 1000;/ / / / BS::thread_pool pool(8);/ / / / for (int i = 0; i < 8; ++i){/ / pool.push_task(thread_function_nano, prios[i], preCT[i], postCT[i], criticalTime);/ / }/ / pool.wait_for_tasks();/ / / / return 0;/ /} / /// using BS thread pool https://github.com/bshoshany/thread-pool in this example./ / / In this example priorities are not given randomly, you can see that I gave 0 priority (the highest priority) to thread 0 which has 2000 + 1000 + 5000 and thread 7 which has 2000 + 1000 + 4500. Priority mutexes function much like a `std::array`, using a 0-indexed based system. For instance, a `priority_mutex<4>` will manage priorities ranging from 0 to 3, with 0 being the highest priority. Currently, the library comprises priority mutexes, both recursive and shared versions, along with RAII wrappers such as `unique_lock` and `shared_lock`, all of which support priorities. There are, however, some elements still missing, including priority condvars and timed versions of the mutexes. The primary motivation behind creating this library is to enhance throughput in multi-threaded pipelines. To illustrate the concept more simply, imagine a pipeline with N tasks, some of which access a protected resource. In cases of contention, there exists an optimal order of resource accesses that minimizes overall execution time, https://sernior.github.io/fairness/ <https://sernior.github.io/fairness/> the images show 2 different ways of ordering critical sections one of which is much better than the other. This library aims to empower developers, who have profiled their software, to manipulate this order with minimal performance overhead and as simply as possible. In terms of implementation, much of the development has revolved around benchmarking and testing. During this process, I've experimented with over 10 different versions of the priority mutex. Ultimately, I achieved the best results by using a priority spinlock, which is also available to library users, to provide internal atomicity to the rest of the mutexes. An essential consideration in the implementation is ensuring that the internal priority spinlock is 128 bytes away from the rest of the memory used by the mutex especially the memory used to perform the atomic::wait on. This separation helps avoid false sharing. The choice of 128 bytes aligns with processor architectures like AMD Zen 4 (the one I am testing on), as indicated in their optimization manual. I can attest that without those 128 byte separation the PM_LockUnlock benchmark was 10X worse and the PM_pipeline_benchmark_fast was worse than the std counterpart (see below for the benchmarks). Another aspect to note in the implementation is the use of 4 bytes for booleans when only a single byte is needed. This decision is related to the way atomic::wait is implemented. Most standard library implementations of atomic::wait check if the type size is supported by the current platform's wait syscall. For instance, Windows can wait on 1 byte, while Linuxkernel based systems can only wait on 4 bytes. These are some benchmark results: 6.4.0-kali3-amd64 AMD Ryzen 5 7600X 6-Core Processor Now the LockUnlock benchmarks were the most difficult to optimize. Those are 8 threads simply doing: m.lock(); m.unlock(); The pipeline benchmarks (with different lenght) are actual pipelines where each thread has different times before/during/after the critical section and I try to set the priorities accordingly to finish as soon as possible. You can see there is also a mutex called slim_priority_mutex, that is a priority_mutex implementation that can support up to 7 (15 if boost atomic is found and your hardware supports the DWCAS) priorities. Those are light weight versions that only take 128 bits up to 7 priorities and past that, up to 15, 256 bits. I am also testing with a custom wait implementations (https://github.com/Sernior/fairness/blob/main/include/boost/fairness/detail… <https://github.com/Sernior/fairness/blob/main/include/boost/fairness/detail…>) which can be tested by defining BOOST_FAIRNESS_USE_EXPERIMENTAL_WAIT_NOTIFY. At some point I wish to make this wait the default version the lib uses instead of the std one since users of my lib could configure this version using my configs macros (number of fast spins - relaxed spins - yield spins before the wait syscall). As I said in the beginning other than to present my lib, this email has the purpose of obtaining feedback. I would like to see if there is anyone (other than me) interested in what I am doing and, if so, consider that I am still far from finished and I would love suggestions. Thank you all for your attention. Best regards, Federico Abrignani.

3 5

[boost.async] new name
by Klemens Morgenstern 13 Oct '23

13 Oct '23

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names: async.core await co_async / cosync co20 / cor20 Thanks, Klemens

14 28

[Async] Naming land grab?
by Niall Douglas 12 Oct '23

12 Oct '23

Dear Boost, I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name. Seeing as nobody here has raised this concern to date, can I confirm everybody here is fine with proposed Boost.Async being called Boost.Async? If you are not, please suggest a preferred alternative name. Niall

21 67

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

Re: [boost] Welcome to our NEW Boost Discourse server! 🥳🎉
by René Ferdinand Rivera Morell 12 Oct '23

12 Oct '23

On Wed, Oct 11, 2023 at 5:33 PM David Sankel <camior(a)gmail.com> wrote: > > On Wed, Oct 11, 2023 at 6:20 PM René Ferdinand Rivera Morell <grafikrobot(a)gmail.com> wrote: >> >> How does one start a new topic in a category through email on this? >> I.e. without using the web UI. Yes, I'm trying to use this thing. > > > It looks like this is something I needed to enable. You can try sending an email to boost+development-4(a)discoursemail.com to post to the boost development category. Why is that not a boost.org email address? Also, where do I find those email addresses? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

2 3

[Async] Peer review report and conditions
by Niall Douglas 12 Oct '23

12 Oct '23

Dear Boost, Proposed Boost.Async by Klemens Morgenstern was reviewed between 8th and 18th August, and again between 22nd September and 2nd October. Reviews or substantially detailed comments came from: - /u/trailing_zero_count on Reddit - Ruben Perez - Marcelo Zimbres Silva - Andrzej Krzemienski - Mohammad Nejati - Janko Dedic - Robert Leahy I would like to thank those above for taking the time to write their detailed comments or reviews, and if I forgot to list anyone, please do forgive me. I did read all reviews and comments as they came in, so even if your name is not listed above, I did take into account your feedback. I would also like to thank all those far too many to list here who gave initial impressions, relaying spelling mistakes in the docs, or otherwise gave feedback of various forms. Boost could not continue without you! The tl;dr; outcome is that proposed Boost.Async is ACCEPTED but with CONDITIONS. Next follows are the **binding** conditions without which the library is not accepted: 1. The library needs to be renamed to something the Boost community doesn’t object to Quite a bit of discussion and feedback surrounded the proposed name “Boost.Async”. Multiple people felt that the name claims too much seeing as it is a C++ 20 coroutines only library, and is from first appearances entirely tied into Boost.ASIO (technically, any ASIO i/o executor can wrap any third party executor, but I can see where people get the strong ASIO association). I agree with Klemens that putting “ASIO” in the new name would be out of character with the other Boost libraries also heavily orientated around Boost.ASIO which do not have ASIO in their name. I find the suggestions that C++ 20 coroutines needs to be somehow in the name convincing. Exactly what form it should take I’ll leave up to the author and community to negotiate, but “Boost.Async” is definitely not a name with good buy-in in the Boost community. It cannot be named “Boost.Async” if it is to enter Boost. 2. The `select()` operation either needs to have its semantics changed, or be renamed Quite a few reviewers found the current semantics unpleasantly surprising, in that a random ready awaitable is chosen and all the others cancelled. This is far away from what `select()` typically means in the C and C++ worlds, and multiple reviewers commented negatively about this. The docs are unclear if it is guaranteed that the first ready awaitable is always chosen, or whether it is _some_ ready awaitable. The difference is important in many kinds of async programming. As this is a single threaded implementation, it should be possible to offer strict guarantees here. The semantics are acceptable if the operation is not called “select”, so I would suggest the easiest course here is to rename that operation to something more acceptable to the Boost community. 3. Channels need to terminate the process if relocated during use, or be made immovable, rather than it being UB to relocate them Some reviewers found the hard UB of moving a channel in use a poor design decision. Hard UB is good if it confers distinct benefits, however reviewers couldn’t see one here, and neither can I. As this library requires C++ 20 in any case, the obvious thing to do is make them immovable, but if that is felt too cumbersome, then they ought to noisily terminate the process or something not footgunny if relocated during use. Other non-binding feedback, which is not a hard condition of acceptance: - Multiple people found the naming of `promise` confusing. A promise is something in C++ land associated with a future, and I suppose in a few years it will also be associated with C++ coroutine awaitables. But here we have an awaitable named `promise`? Yes I know it makes sense in other programming languages, but here in C++ land it just seems weird and confusing for no obvious gain. I personally would suggest `eager_task` and `lazy_task` but I have no especially strong opinions on naming here other than that `promise` is a poor choice for any awaitable type. In fact, I think just don’t put the word “promise” into any awaitable type period. - I am sympathetic to multiple people raising the lack of preconditions and postconditions on operations described in the documentation. I also accept that in an async world, it’s hard to be precise. However, I think it would be a large benefit to the documentation to describe for each operation a list of the ways in which it can fail, and I think this should be added. - Andrzej took issue with the design of the generators, and I can see why. However, out in real world code land, C++ coroutine generators have surprisingly large amount of design variation. I’ve seen ones which you loop on testing them for boolean true, I’ve seen others which loop on their iterators, I’ve even seen ones which don’t implement either boolean true nor iterators and require you to call a `value()` member function which returns an Optional. Why? No idea, people seem to innovate uselessly here for some reason. I think it wise to adhere to `std::generator` from the standard, and do exactly what it does. From my reading of Async’s `generator`, whilst it has extensions e.g. the invocable call operator, the only thing missing is the iterator interface to make it implement `std::generator` and I don’t see any obvious reason why an iterator interface can’t be added here? - I agree with Andrzej about ever throwing `std::logic_error`, it should not be done in newly written code. It is recognised as a mistake by most on the standards committee nowadays. - The Mersenne Twister is a poor PRNG by modern standards. You should use JSF or anything else both much faster and higher quality. - More than one reviewer wants the docs to do a much better job on documenting pseudo-awaitables and awaitables and `await_transform`. - Quite a few times the docs talks about “async” when it really means “C++ coroutines”. - I think the docs does a poor job of disambiguating when what it is describing is part of the C++ standard, or it is part of Boost.Async. The reason this is important is that users need to know when/if they are locking themselves into Boost.Async proprietary extensions vs standard C++ coroutines. Finally, as a personal note on the review, it was notable how much negativity there currently is against C++ coroutines in general from the C++ community. A small number of us have been writing C++ coroutine code for many years now, we have been through the process of getting footgunned over lifetime issues, got frustrated that these coroutines are not the coroutines we were looking for, and eventually came round to understanding what C++ coroutines are good at solving, and more importantly what they are NOT good at solving. Once your head is wrapped around that, then comes the problem of having to reinvent a C++ coroutine support library because all the current open source ones have severe issues, especially around very tight coupling being imposed on your codebase. I don’t personally agree with every design decision in proposed Boost.Async, but I do think this will be a major step forward in making C++ coroutines accessible to many more developers than now, especially because this is to my knowledge the first standards-based loosely coupled C++ coroutines library which is open source. Undoubtedly after it ships with Boost, deficiencies will be found both in this library and in the currently quite poor quality implementation of C++ coroutines in the three major compilers. I very much hope that the increased number of developers using C++ coroutines as a result of this new Boost library will result in large and substantial improvements in implementation and library support of C++ coroutines. My thanks to Klemens for putting the work into what is a controversial and opinionated library design quite unlike any other currently available. It’s not easy to tread new ground without much precedent. My thanks to the Boost and Reddit communities for their ample and detailed review feedback, which made me managing this review possible.

5 13