- Boost - lists.boost.org

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

Seeking Endorsement for Charconv
by Matt Borland 22 Sep '23

22 Sep '23

Hello, At the beginning of the summer I solicited feedback for an in-progress C++11 implementation of <charconv> for a proposal to Boost. The library is now complete with that feedback incorporated, and I am seeking endorsement. Should the library receive endorsement Chris Kormanyos has volunteered to serve as the review manager. What is Charconv? It is a character conversion library that converts a character sequence into a number (from_chars) or converts a number into a character sequence (to_chars). This is similar to strtod and printf with two key differences. First and most important is a roundtrip guarantee. That is a number converted into a character sequence, and then back into a number will be identical to the starting value. Second, you can easily specify an input/output format with a chars_format argument, and also provide a target precision. Lastly, instead of requiring recent compilers (e.g. GCC 11, and MSVC 19.24) and C++17 to get full support for <charconv> you can have it now with GCC 5, Clang 3.7, or MSVC 19.00 and C++11. What types are supported? All builtin integers plus __int128 and unsigned __int128. For floating point types all built-in IEEE 754 compliant types to include those provided in C++23’s <stdfloat>, and __float128. A notable example of a non-IEEE 754 compliant built-in type is ibm128 provided on older versions of PowerPC. How do I use the library? The repo can be found here: https://github.com/cppalliance/charconv. Since this is a compiled library, directions for use with b2, vcpkg, and conan are provided. What is the performance like? I added a table of benchmarks (https://master.charconv.cpp.al/#ref_benchmarks) that compares this implementation to the performance of: STL (printf, strtoX, and <charconv>), Boost.Lexical_Cast, Boost.Spirit, and libdouble-conversion. In summary we meet or exceed the performance of GCC and MSVC <charconv>, and exceed by up to several multiples the performance of all the other libraries. Thanks to Stephan T. Lavavej for providing his benchmarking file in the original discussion. Why is this not going into Boost.Compat? The size of this library exceeds the scope of Boost.Compat. Compat is designed for headers that can be implemented in a small amount of code. <latch> with implementation, testing and documentation was ~350 LOC while Charconv is ~29,500. Please let me know if you have any questions or issues with the library. Thanks, Matt Borland —- C++ Alliance Staff Engineer

5 7