- Boost - lists.preview.boost.org

[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

Async review scheduled for September 22, 2023 - October 2, 2023
by Mateusz Loskot 08 Sep '23

08 Sep '23

Hi, Following request from Nial and Klemens, we have scheduled new round of the Async review for September 22, 2023 - October 2, 2023 https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, on behalf of the Review Wizards

3 2

Presenting BoostServerTech chat
by Ruben Perez 07 Sep '23

07 Sep '23

Hi all, I'm Ruben, the author of Boost.MySQL, and I want to present (and maybe get some feedback about) a project I'm developing to showcase how to do async stuff with Boost server-side. This started because I want to write a connection_pool class for MySQL. It's a complex feature with a lot of trade-offs, and I wish I had more field experience to guide me when making the required decisions. We currently have great libs for async networking (Asio, Beast, Redis, MySQL). They've got examples and docs, but I think they sometimes fall short. Often users get lost since setting up an async server is not trivial, and we offer a lot of flexibility that can sometimes stun newcomers. So I've decided to blend these two needs together and create a project that allows Boost authors to try new things in a realistic environment, while demonstrating to users how they can use Boost to build an app. (Note: this is **not** a Boost library, and will never be). Code: https://github.com/anarthal/servertech-chat/ Docs: https://anarthal.github.io/servertech-chat/ Live demo: http://13.48.215.34/ It's still a work-in-progress. Although I've implemented some features, I've tried to focus on the skeleton, getting testing, deployments and C++ best practices in place. I plan on adding more stuff in the future, like showing how you can call 3rd party REST APIs using Boost. One cool feature is that, if you have an AWS account, you can fork the repo and get a live server in minutes (see https://anarthal.github.io/servertech-chat/03-fork-modify-deploy.html) I actually envision this as a series of projects, showcasing different applications and needs. I originally wrote this document (https://docs.google.com/document/d/1ZQrod1crs8EaNLLqSYIRMacwR3Rv0hC5l-gfL-j…) describing how I saw it. If any other author wants to step forward and create their own ServerTech application, please let me know. I'd like to have some (hopefully constructive) feedback from you guys. I'd thank you if you give the live demo a try. And if someone's interested, there's a ton of work to do, so let me know. Note: if you've scanned through the code and you're asking "where is the connection_pool" - nowhere yet, that's still to come. Thanks, Ruben.

5 8

Boost Solvers Library
by Pascal Kesseli 03 Sep '23

03 Sep '23

In the course of my research in static program analysis, I have been a contributor to the Bounded Model Checker for C (CBMC - https://github.com/diffblue/cbmc) for quite some time now. Projects like these map static analysis problems to a variety of back-end solvers like SAT, SMT, QBF, etc. What always surprised me is how often tools like CBMC have to come up with an intermediate C++ layer for the various back-end solvers like MiniSAT or Glucose (see https://github.com/diffblue/cbmc/tree/develop/src/solvers/sat) For this reason I am considering to create a unified C++ wrapper for these different solvers, with an initial focus on SAT. I intend to include a naive default DPLL implementation, but the real value for such a library would stem from making the aforementioned third party engines easily accessible. I was wondering whether this would be a fit for a Boost library, but I am uncertain whether: A) There is even interest in the community for this or B) The scope of the library with inherent dependencies on external SAT solvers fits the Boost format Thus I thought I'd drop this message in the mailing list to ask what people think. Thanks,

1 0

[boost.async] Some feedback
by Andrzej Krzemienski 29 Aug '23

29 Aug '23

Hi Everyone, I will not be able to write a decent review due to the lack of time (I am now on vacation), but I wanted to share some partial feedback. I am not well familiar with C++ coroutines. I wrote some toy examples of an async TCP echo server in ASIO in the past, to try to learn how coroutines work, but my knowledge is very superficial. I hoped to understand coroutines better from studying Boost.Async's docs. When I discovered Boost some 18 years ago, I found it useful not only because of the high quality libraries but also because of extraordinary documentation that often provided a very deep insight into the problem domain, a lot of rationale, design goals, and the documentation of engineering trade-offs of different sorts. I do not know how people feel about the importance of documentation nowadays. For me, however, it is the primary focus. I devoted like 10 hours in total for studying the docs and running some toy examples. Because I am not very good at C++ coroutines, you get a typical, I would think, feedback from a user that wants to learn how coroutines are used, what problems they solve, and what problems they do not solve. Regarding the *really* asynchronous part, promises and tasks, I guess they would work fine. By "really asynchronous" I mean the situations where a coroutine is resumed by events unpredictable by the programmer (when data arrives, when certain time passes, when an external connection is requested). I also guess that when Marcelo and Ruben say they successfully integrated Boost.Async into their projects, they meant types `task` and `promise`, rather than `generator`. My investigation was interrupted by `generator` which I cannot understand or appreciate. It feels like a type quite separate from the rest of the library. For instance, through all the simple examples in the docs, only the examples for `generator` never use the trick with `co_await async::this_coro::executor`. I needed to ask a lot of questions, and even though Klemens is very responsive and very helpful, I still do not understand how `async::generator` solves real problems. This may indicate that either I am a very slow learner, or that there is something wrong with the design of `generator`. But even if it is the former, I think I represent the average user of this library. When I try to use a C+23 std::generator, the usage is intuitive and straightforward to me. I know how to easily yield a sequence of values, and on the caller side how to easily check if I can still obtain the next value from the generator: ``` std::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } int main() { for(int i : seq(1, 4)) std::cout << i << std::endl; } ``` https://godbolt.org/z/PTvz3v4Y6 But when I try what I believe to be an analogous example in Boost.Async, I get an exception: ``` async::generator<int> seq(int from, int to) { for (int i = from; i <= to; ++i) co_yield i; } async::main co_main(int argc, char* argv[]) { auto s = seq(1, 4); while (s) { std::cout << co_await s << std::endl; } } ``` And the docs or examples don't help me understand why this use case doesn't work. The case with the eager generator that can be injected values is even weirder. I think it is wrong. Klemens thinks otherwise, but the docs do not give any convincing example of where and how it could be used. The lack of examples or description can be just that, but it could also indicate that the design for generators is missing something. In this feedback, I am only mentioning generators, because this is the place where I stuck in my review. I guess that other parts of the library do not have this problem. I am pretty sure that this library will be accepted into Boost at some point. It addresses a real need (although not necessarily the generators), and the feedback from Ruben and Marcelo are strong testimony to the quality of the library. But at this point, I am not comfortable with adding a library whose design for generators cannot be explained in the docs to the extent that I consider satisfactory. Would this library lose in usability if generators were removed? I know it is not a fair review. I only covered one subject, and my feeling is that it is not the most relevant one. So please consider it as "just feedback" rather than a review. Again, thanks Klemens for writing and sharing this library. I hope that this message does not come across as negative. I want to think that I am contributing to the quality of Boost.Async. Regards, &rzej;

2 2