- 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

Welcome to our NEW Boost Discourse server! 🥳🎉
by Inbal Levi 11 Oct '23

11 Oct '23

Hello everyone! Boost board has been working on a few improvements lately, one of which is to create a new *Boost Discourse server: https://discourse.boost.org/ <https://discourse.boost.org/>* The server is meant to allow more interactive and convenient development in the boost community, and we'll be happy to have you all there! *To join the server:* 1. Go to the URL: https://discourse.boost.org/ 2. Login to the discourse server 3. The server contains three categories: 1. Beginners - start here if you're new to Boost or to discourse 2. Boost Development - go here to create a new topic of discussion (roughly, we expect every new library will have its own discussion thread) 3. Community - go here if you'd like to start a thread about community topics, or if you'd like to talk about anything that doesn't fit the first two topics :) *To start a technical discussion:* 1. log-in 2. Go to the "*Boost Development*" category 3. Click on "+ New Topic" (in the right upper corner), and add a new discussion topic for your library! [image: image.png] Please review our Code of Conduct <https://cppnow.org/about/code_of_conduct/> before participation. We expect a respectful and positive discussion! If there are any technical issues, feel free to approach me at: sinbal2lextra(a)gmail.com or any other of the server admins: jeff(a)crystalclearsoftware.com, camior(a)gmail.com, whatwasthataddress(a)gmail.com Looking forward to seeing you all in our new discourse server! 🤗 Thanks, Inbal Levi, in the name of the Boost Foundation board members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *Lead Software Engineer @ Millenium* Isocpp, Boost &"Hamakor" Non-Profits Board Member ISO C++ LEWG Chair & Israeli NB Chair C++Now Program Chair & CoreC++ Conference Organizer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 8

Mutual respect
by David Sankel 10 Oct '23

10 Oct '23

Some comments in the boost Async discussion were unconstructive and disrespectful. I want to remind folks that this is not how this community operates and thrives. Technical disagreements are, of course, fine and encouraged but we don't cross into putting people down, imputing nefarious motives, or disrespecting people's efforts. Thanks, -- David

2 1

Raising minimum target Windows version
by Andrey Semashev 08 Oct '23

08 Oct '23

Hi, I'm considering raising minimum target Windows version for my libraries to at least Windows 7. This means dropping workarounds for missing WinAPI functions that are present (but, for a very long time now, untested) for Windows XP. This specifically pertains to Boost.Atomic, Boost.Filesystem and Boost.Log. I'm also tempted to raise the requirement to Windows 8 to have access to WaitOnAddress & co., but I'm hesitant since Windows 7 might still be wide spread (perhaps, not on desktop but embedded). The current plan is to announce this in the release notes for the upcoming 1.84 release and drop the support in 1.85. This will mean the dependent libraries and tools will similarly drop support for older Windows versions. Additionally, I'm proposing to raise the default target Windows version in Boost.WinAPI to Windows 10, provided that the Windows SDK that is detected in compile time supports it. This means that by default many Boost libraries that rely on Boost.WinAPI for WinAPI definitions will target Windows 10. Which, in particular, means the prebuilt binaries we distribute will require Windows 10, unless libraries take explicit measures to stay compatible with older versions. I have no fixed time frame for the proposed Boost.WinAPI change, but it could be done as soon as in 1.84, since this doesn't remove anything, just changing the default. Comments? Objections? Counter-proposals? I'm especially interested in comments regarding Windows 7 as the new baseline - am I being too conservative? Thanks.

6 10

issue with boost::any documentation
by jepessen＠wteam.it 06 Oct '23

06 Oct '23

Hi. I was reading the online documentation for boost::any, when I went to this page: https://www.boost.org/doc/libs/1_83_0/doc/html/any/ValueType.html clicking on the next arrow will go to this page https://www.boost.org/doc/libs/1_83_0/doc/html/reference_section.html that seems a page of boost::PFR instead of boost::any. In fact, by clicking on next and previous arrows, allows navigating to PFR documentation. Im not an expert on about how documentation works, so I dont know how fix it and make a pull request. What should I do? Daniele Lupo

2 1

[Async] Review from Janko Dedic
by Niall Douglas 02 Oct '23

02 Oct '23

This was sent to me privately with an express wish it be posted here. I don't know if the author is subscribed here, so I don't know if replies will be seen. This is the first REJECT review. Niall --- cut --- What follows is my review of the proposed Boost.Async library. >Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. I have considerable experience with C++ coroutines as I've been implementing my own coroutine types in the past. I have used Asio before in a professional setting, although I wouldn't call myself an Asio expert. My experience involved using Beast/Asio to perform HTTP requests and sending fan-out notifications to external subscribers. Notably, I have a lot of experience with asynchronous programming in other programming languages, mainly Java, Kotlin and JavaScript, but I'm also very familiar with how it works in Go and Rust. I would say I've spent around 10 hours evaluating the proposed library. When I first saw this library being proposed, I was hoping it would provide a more modern, capable and ergonomic version of asynchronous programming, like other modern programming languagues and unlike Asio. The goal of this library is seemingly not to provide such an out-of-the-box seamless solution, but very specifically to provide certain coroutine-related utilities and enable composition of different coroutine types, including user-defined coroutine types (unlike `asio::awaitable`). However, I don't think either characterization is entirely correct, and Boost.Async finds itself in an awkward middle. On one hand, it does not build on top of Asio to provide a modern and seamless experience which would completely replace the direct usage of Asio (which is exposed front-and-center in the interface and code using this library has to also use Asio a lot to get the job done). On the other hand, it's also not a completely generic "coroutine library" that only provides abstractions based on C++ coroutines that could be used by any library (because it depends on Asio specifically). In my view, the correct way to characterize this library would be to regard it as a bundle of coroutine-related utilities on top of Asio. However, the library is evidently not entirely compatible with any kind of Asio usage as it's focused on "simple single threaded asynchronicity." It can certainly be used in conjunction with Asio, but it definitely brings some additional nuance and complexity (which I don't think is good, considering that Asio has a lot of complexity of its own). When it comes to added functionality, there are definitely some welcome additions in the form of `async::with` for asynchronous clean-up, `async::select`, generators. What mainly stands out to me is channels, which are a very important bread-and-butter feature for many languages. However, we should keep in mind that Asio has some experimental support for channels as well, and users of this library would probably be faced with an unnecessary choice sometime in the future. One of the most advertised features is the ability to "compose arbitrary third party awaitables without any additional effort, which lets you tie together third party libraries with ease and convenience". Firstly, I don't think this is a goal worth pursuing. As a user, I would definitely want as few coroutine types as possible in my codebase (ideally one). `asio::awaitable` already nicely fits the bill. I very well understand that we need at least a few more for sync/async generators, but that's where I'd draw the line. Secondly, this library does not exactly fulfill the promise of "tying together third-party libraries with ease". Boost.Async does not work with any coroutine library out of the box. For example, my coroutine types are incompatible with it and the code doesn't compile. Same goes for `asio::awaitable`. There is definitely some integration effort necessary to wrangle these distinct types to work together. Related to this, I also dislike exposing the whole C++ coroutine machinery as some kind of a first-class "standard" API for integrating different coroutine types together. There is evidently no "standard" API for integrating different coroutine types as arbitrary coroutine types won't simply work together out of the box. Additionally, having used the standard coroutine customization points myself, I can't say I like this API at all and I consider it a necessary evil. It is very subtle, error-prone and hard to reason about. This is definitely not something that should be exposed to the users of the library, even experts. Implementing one coroutine type is hard enough, but making sure that two coroutine types from different authors work together is even harder. Considering the complexity of the standard coroutine API, even if my coroutine types compiled with this library's types, I would not trust the whole thing to actually work in all the edge cases. I believe `asio::awaitable` made the right choice here. I have built the library and played with the examples a bit. I've tried integrating it with my own coroutine types as I've described above. The documentation is filled with examples, which is good, but the reference section is lacking a bit in a sense that it doesn't document the signature, arguments, the return type, preconditions etc. as you would expect. I don't see this is a major issue because the documentation can always be improved, and perhaps we still have to discover how to effectively document coroutines because of how unique and different they are. I vote to REJECT this library on the basis outlined above. This is definitely an admirable effort and I want to see more progress for C++ in this direction, because the standardization efforts are not promising and there are still no open-source libraries comparable to the likes of Rust's Tokio and Kotlin's standard library. Unfortunately, I don't think this library is a step in the right direction. All the best, Janko Dedic

2 1

PSA: C++11 libraries need to update their libraries.json and CMakeLists.txt
by Peter Dimov 02 Oct '23

02 Oct '23

Libraries that now require C++11, such as Atomic, TypeIndex, LexicalCast, need to update their libraries.json files to now state "cxxstd": 11, and to add the C++11 requirement to their CMakeLists.txt files, e.g. target_compile_features(boost_lexical_cast INTERFACE cxx_std_11) boostdep --cmake looks at libraries.json and automatically adds the above requirement, so for generated CMakeLists.txt files (such as the one in lexical_cast), a simple regeneration with e.g. `boostdep --cmake lexical_cast` will suffice. Note that cxx_std_11 requires CMake 3.8, so the cmake_minimum_required line may need to be adjusted as well. (`boostdep --cmake` does that automatically.)

2 4

Windows Regression Runners - Failing on Develop
by Tom Kent 02 Oct '23

02 Oct '23

Starting sometime between 3am and 5pm on September 11, 2023, all the windows regression runners started failing on the develop branch. Master branch runners on the same VM are still doing fine ( https://www.boost.org/development/tests/master/developer/summary.html) The output doesn't have anything jump out at me. Nor were there any commits to the develop branch in that window that seem suspicious to me. The regression run output ends with: ...found 1 target... # Searching for "process_jam_log.exe" in "C:\teeks99-09\run\boost_regression\stage\bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 286, in __init__ self.main() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 580, in command_regression self.command_setup() File "C:\teeks99-09\run\boost_regression_src\regression.py", line 351, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 714, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "C:\teeks99-09\run\boost_regression_src\regression.py", line 739, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log.exe" in any of the following locations: C:\teeks99-09\run\boost_regression\stage\bin\process_jam_log.exe C:\teeks99-09\run\boost_regression\stage\bin With the full output available here: https://gist.github.com/teeks99/bb4230f6a1efdd7af11bd93341c950bf Any ideas on this would be much appreciated.

5 15

Dropping support for InPlaceFactory from Optional
by Andrzej Krzemienski 01 Oct '23

01 Oct '23

Hi Everyone, I would like to get the community's advice on removing the support for InPlaceFactory from Boost.Optional. The motivation for this is to reduce dependencies among Boost libraries. Boost.Optional is surprisingly heavy. This is mostly due to the dependency on InPlaceFactory and OptionalPointee from Boost.Utility. https://pdimov.github.io/boostdep-report/develop/module-weights.html#weight… InPlaceFactory ( https://www.boost.org/doc/libs/1_83_0/libs/utility/doc/html/utility/utiliti…) used to be a workaround for the missing "perfect forwarding" in C++03, it emulated both "universal references" and variadic templates. It is unnecessary for C++11 where Boost.optional offers a superior interface. But removing the support for InPlaceFactory would break code for people that happen to use it. When the user switches to C++11 (C++03 support is deprecated for Boost.Optional) they should expect their programs to still compile. But if I remove the InPlaceFactory, it forces the users to change their code, even if they are already on C++11. Can InPlaceFactory be moved to a separate library? Or is it so useless now that it has to be eradicated even at the cost of breaking users' code? I would welcome any suggestions. Regards, &rzej;

3 3

[boost.async] Andrzej's review
by Andrzej Krzemienski 01 Oct '23

01 Oct '23

Hi Everyone, I would like to thank Klemens for writing and sharing the Async library. It is something the community needs, and it is clear that a lot of thought and effort was put in it. I am not an expert on C++ coroutines or coroutines in general. I have played with a few echo-server examples in the past from Boost.ASIO, and created some toy examples of C++ coroutines. I devoted something like twelve evenings studying the Boost.Async: reading docs, testing toy examples (Windows 11, MSVC 2022), debugging and asking Klemens a lot of questions. Still, I cannot say I understand the library well enough to be able to responsibly give a recommendation. But I can still share my observations. On the design. Although my knowledge is superficial, I will risk a claim that the synchronization mechanisms and supporting features (`with`, channels, work_group) are the strong part of the design. (I disagree with the overload set for `select`, but I guess this is a non-design bug.) Regarding the choice and design of "coroutine types", I have certain reservations. It is still not clear to me why we have two -- promise and task -- and when I should use which. The docs give some answer: promise is eager, task can be awaited/spawned on another executor than it was created on. But is that it? I sense that there is a good reason to have them as two types, a better/clearer one than this described in the docs.But I fail to see it, and the docs do not explain it clearly enough, I think. I am uneasy about the design for `generator`. I filed a couple of issues: https://github.com/klemens-morgenstern/async/issues/101 https://github.com/klemens-morgenstern/async/issues/70 One problem is how the `generator` signals that it has finished. In all the examples it has to create a dummy value. I hear from Klemens that it is a necessity imposed by the coroutine design in C++. I do not feel competent to confirm it or not. But I note that std::generator does not require the user to `co_return` anything. And that asio::experimental::coro does allow the user to specify that they do not want to co_return even if they co_yield things. Regarding the value-returning generators, I have even more reservations. As noted in one of the quoted GitHub issues, the fact that it has a different interface than the normal generator, and that it has to be lazy to be usable, It looks to me like it qualifies for a separate coroutine type. On the documentation. The only other library offering coroutine support and any documentation that I know of is Boost.ASIO. In comparison to Boost.ASIO, Boost.Async has a waaay better documentation. It is big (in a positive sense), it has a lot of tutorial materials, lots of ideas explained, it is still being improved. It is waaay above the average quality of a library documentation that you can find on the web. But still I would greatly appreciate an even better one, however arrogant that seems. My reasoning is that for the next couple of years people who will consider Boost.Async will not only be unfamiliar with the library but also with C++ coroutines in general. They will need additional extra help to be able to use the library responsibly. To be more specific, I would expect more full compiling examples (those in folder examples) that illustrate different aspects of the library. For instance: * A convincing example of value-returning generator * timeout implemented in terms of `async::select`. I would expect a more detailed explanation of concepts used in this library: * interruption and cancellation, and how they differ, and when/if I should care about them. * being detaching and being detached, and how it is different from spawning. I got a response in one of GitHub issues that, "Interrupt is [...] meant to make select work lossless. What gets detached is the co_await itself, not the awaited thing." I feel the documentation should explain it more cleanly, and perhaps introduce some more well defined terms. The library does not cleanly communicate preconditions on the operations. I think it sometimes decides to throw an exception when a precondition is more appropriate. In other places it is silent about the corner cases. It also does not specify clearly what is guaranteed of the provided operations. Klemens correctly points out that postconditions are tricky in the case of asynchronous operations, but (1) some things in the library are not asynchronous and (2) this library (like any other) does offer some guarantees, if not on individual function calls, then for the entire expressions. For instance `co_await select(aw1, aw2)` does provide a guarantee that the result of one of the awaitables will be returned and the others will be interrupted. It should be specified in the synopsis of `select`. On the implementation. It is mostly magic to me, so I do not have much to say. There are a lot of awaitable types created whose existence I could not predict from studying the docs. I cannot say if this is a deficiency of the documentation, or is this how the C++ coroutines work: you might need a lot of awaitables that are implementation details. I find the design of the overload set of functions `select` bad and generic-programming-unfriendly. I explained it in detail in: https://github.com/klemens-morgenstern/async/issues/103 Functions that do slightly different things should have different names. Returning different types for special cases breaks generic code, and causes surprises, sometimes runtime surprises. Also, because the overload for value-returning promises returns a variant, I have run into an interesting situation when trying to add a timeout support to the echo server example. I get the following statement: ``` variant2::variant<variant2::monostate, tcp_socket> ans = co_await async::select( timer.async_wait(async::use_op), acceptor.async_accept() ); ``` And now I have a variant to unpack inside a coroutine. Normally, the recommended way to unpack a variant is to use a visitor: ``` struct visitor { void operator()(tcp_socket&& sock) { co_yield std::move(sock); // ERROR } void operator()(variant2::monostate&&) { } }; visit(visitor{}, std::move(ans)); ``` But this doesn't work, because now I am co_yield-ing from a non-coroutine. And I have to resort to manually inspecting the variant, which is taught to be error prone. I guess this is the right choice to use variant for the return type of `select`, and that it is the limitation of variant, until C++ gets pattern matching. But still, it would be helpful if the documentation (or examples) illustrated what potential difficulties the user can expect. Should the library be accepted to Boost? Again, I am not competent enough in the domain of coroutines, to responsibly say that the library meets the bar, but because I think the community desperately needs this kind of library with Boost-quality docs and support, I will risk saying that Boost.async should be conditionally accepted. The conditions being: * Address the design of generators (either change it or provide a clearer rationale) * Improve the docs - clearly describe the notions of interrupting, canceling, detaching, spawning. - provide a more detailed synopses for functions and classes with preconditions, described effects, and the guarantees. I filed this as a list of issues in the GitHub: https://github.com/klemens-morgenstern/async/issues/120 https://github.com/klemens-morgenstern/async/issues/119 https://github.com/klemens-morgenstern/async/issues/117 https://github.com/klemens-morgenstern/async/issues/115 https://github.com/klemens-morgenstern/async/issues/114 https://github.com/klemens-morgenstern/async/issues/103 https://github.com/klemens-morgenstern/async/issues/101 https://github.com/klemens-morgenstern/async/issues/100 https://github.com/klemens-morgenstern/async/issues/70 https://github.com/klemens-morgenstern/async/issues/64 Finally, while the above might look like a list of complaints, I really appreciate the work that was done in order to provide this library, and the solutions that were applied (like the clever use of await_transform). I learned a lot from studying this library, and my intuition tells me that it will end up being a great addition to Boost. I also appreciate the responsiveness of the author. Klemens has been answering a lot of my questions in a timely fashion, and improving the docs based on feedback. Thanks! Regards, &rzej;

2 2

[Async] Second attempt at review of proposed Boost.Async begins
by Niall Douglas 01 Oct '23

01 Oct '23

Dear Boost, Due to too few reviews last time, we are going to try again the review of this library. This review shall run between Friday 22nd September and Monday 2nd October. Please do consider contributing a review! My thanks to Marcelo Zimbres Silva for the only formal review last time, and to the others including those on Reddit /r/cpp and by private email who submitted feedback. All your reviews and feedback have been retained and will be reused for this review. To remind you all, Boost.Async is a C++ coroutine programming library based around Boost.ASIO as the executor, with a unique set of properties which make it incomparable to most existing C++ coroutine programming libraries. To be specific, it lets you compose arbitrary third party awaitables without any additional effort, which lets you tie together third party libraries with ease and convenience. Changes to proposed Boost.Async since the last review: 1. Major doc improvements & bug fixes 2. PMR is optional 3. optimized associated allocator for use_op 4. lazy generator support 5. public unique_handle & more examples with custom awaitables 6. as_result/as_tuple support (akin to the asio stuff, but takes an awaitables, i.e. co_await as_result(foo())) - reduces unnecessary exceptions. 7. with supports return values. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Anyone with experience using C++ coroutines is welcome to contribute a review at the Boost mailing list (https://lists.boost.org/mailman/listinfo.cgi/boost) at /r/cpp on Reddit, via email to me personally, or any other mechanism where I the review manager will see it. In your review please state at the end whether you recommend acceptance, acceptance with conditions, or rejection. Please state your experience with C++ coroutines and ASIO in your review, and how many hours you spent on the review. Thanks in advance for your time and reviews! Niall

4 4

[Async] Reminder that peer review ends on Monday
by Niall Douglas 29 Sep '23

29 Sep '23

A reminder to Boost folk that the proposed Boost.Async review ends on Monday 2nd October. I have received no new reviews since this second review began. You can read the documentation at https://klemens.dev/async/ and study or try out the code at https://github.com/klemens-morgenstern/async. Niall

2 1

Re: [boost] Fwd: [boost.async] Andrzej's review
by Niall Douglas 29 Sep '23

29 Sep '23

Andrzej, Firstly, it's weird I don't see this on the Boost mailing list. In fact, I seem to only get about half the mail to the Boost mailing list ever since they fiddled with the servers. So thanks for sending this review to me directly. I've also caught up with all your other posts on Boost.Async from https://lists.boost.org/Archives/boost/2023/09/index.php, none of which I had seen before now. Thanks for the review. If you don't mind if I jump in with a few bits myself which are intentionally not about the review itself ... On 29/09/2023 14:08, Andrzej Krzemienski wrote: > Regarding the choice and design of "coroutine types", I have certain > reservations. > It is still not clear to me why we have two -- promise and task -- and > when I should use which. The docs give some answer: promise is > eager, task can be awaited/spawned on another executor than it was > created on. But is that it? I sense that there is a good reason to have > them as two types, a better/clearer one than this described in the > docs.But I fail to see it, and the docs do not explain it clearly > enough, I think. Outcome calls the same thing eager and lazy. I felt lazy is a more descriptive name than task. I mean, why should a task be lazy rather than eager? The reason is simply because Lewis Baker happened to choose that default, and it's stuck since, but there isn't any strong rational for "task ~= lazy" other than convention. > One problem is how the `generator` signals that it has finished. In all > the examples it has to create a dummy value. I hear from Klemens that it > is a necessity imposed by the coroutine design in C++. I do not feel > competent to confirm it or not. But I note that std::generator does not > require the user to `co_return` anything. And that > asio::experimental::coro does allow the user to specify that they do not > want to co_return even if they co_yield things. It's been a while since I used coroutine generators, but my memory is when the coroutine exits then the generator returns its end iterator value. I don't remember dummy values. But then I 99.9% use C++ coroutines with Result, to avoid ever throwing C++ exceptions through C++ coroutine machinery which *still* is riddled with showstopper bugs in current compilers. > On the documentation. The only other library offering coroutine support > and any documentation that I know of is Boost.ASIO. There are actually a good few Boost libraries with C++ coroutine support now in one form or other. Outcome is obviously one, but there is at least one other apart from ASIO (somebody else may remind me which one now). Boost.Async's are much fuller featured obviously, but even Outcome's simple ones are usually good enough for most use cases. You don't need to use them with Result either. > But this doesn't work, because now I am co_yield-ing from a > non-coroutine. And I have to resort to manually inspecting the variant, > which is taught to be error prone. BTW tip for the future: just use helper coroutine lambdas if you need to do coroutine stuff from within normal code. These normally don't work with the Coroutine support from cppcoro, stdexec, libunifex nor ASIOs because their coroutines don't allow it. But Boost.Async's does, as does Boost.Outcome's. It cannot be understated the usefulness of being able to dip in and out of "coroutine land" using inline lambdas from normal code. It makes C++ coroutines vastly more convenient to use. Niall

2 1

[fiber] Moving fibers between threads
by Niall Douglas 28 Sep '23

28 Sep '23

Dear Boost, At work I need to move a Boost Fiber from one kernel thread to another. There is a dedicated documentation page for this: https://www.boost.org/doc/libs/1_83_0/libs/fiber/doc/html/fiber/migration.h… What that page doesn't say is how to migrate yourself if you're currently within a Fiber to another kernel thread, as the docs only talk about migrating Fibers currently not executing and in the ready not sleeping state. I guess this would work: 1. Create a new Fiber, and go into a loop giving up the current execution. 2. When that new Fiber executes, migrate the original fiber to its new kernel thread, then have it exit the loop so it proceeds. Then self immolate, as you're done. But now you're creating and destroying a whole Fiber just to migrate a Fiber between kernel threads, and that feels icky. I don't suppose there's a better way e.g. some sort of way of asking the current thread's Fiber scheduler to call a function when it's next not executing a Fiber? That would avoid the needless Fiber creation and destruction per migration of a Fiber across kernel threads. Thanks for help in advance. Niall

3 3

[boost.async] Dummy co_return from a generator
by Andrzej Krzemienski 24 Sep '23

24 Sep '23

Hi Everyone. I am very uneasy about the dummy co_retuned value that I see in the examples of async::generator. Like the one in the echo server example: https://klemens.dev/async/tutorial.html#echo_server async::generator<tcp_socket> listen() { tcp_acceptor acceptor({co_await async::this_coro::executor}, {tcp::v4(), 55555}); for (;;) { tcp_socket sock = co_await acceptor.async_accept(); co_yield std::move(sock); } co_return tcp_socket{acceptor.get_executor()}; // :-( } The control will never get to the co_return. The caller never even tries to observe this value. and yet we are forced to return it. Interestingly, the coroutine example from ASIO doesn't have this due to a different design: https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/example/cpp20/cor… std::generator doesn't have this. In other examples the degenerate value is used to indicate the end of generation. I do not know the coroutines to be able to tell if this is a design problem with async::generator or with C++ coroutines in general. But it feels wrong that the end of generation should be signaled in this way. Regards, &rzej;

2 5

[boost.async] a note on documentation
by Andrzej Krzemienski 23 Sep '23

23 Sep '23

Hi Everyone, In the context of the Boost review of Boost.Async, I wanted to share a thought on documentation. I think the Reference section in the docs is insufficient. A lot of libraries in Boost have this approach that the reference section of the documentation is a specification exhaustive enough that it could be used to provide a number of competing implementations. Each function has a very detailed contract: what it returns and when, what are the preconditions, what exceptions are thrown upon failure, what are the postconditions. I am missing this from the reference of Boost.Async. Also, it may be one of the first libraries (that meet a certain bar of documentation) tied so much to coroutines, so I have no strict requirements on how a coroutine library is documented, but I think things like promise types should be explicitly referenced. Let's consider `async::generator`. It is not only class template `generator`, but also: 1. the specialization of type trait std::coroutine_traits 2. Class template `generator_promise` 3. generator_promise 4. generator_receiver 5. awaitable types Even though some of them belong to namespace `detail`, they provide guarantees relevant for the users. I do not think `generator_promise`is an implementation detail. I think it needs to be documented. This seems especially important when I start adding my awaitables to the mix. I wonder what others think about it? Regards, &rzej;

2 5