On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost wrote:

I'm not going to submit a review but I do think the name is almost a misnomer.

The library is essentially just an Asio wrapper and isn't a genuine coroutine library.

What would be a genuine asynchronous coroutine library?

I think the name Async gives the wrong impressions and expectations in addition to being much too generic of a name for what the library actually does.

What would be those expectations? What functionality should it include?

On Mon, Oct 2, 2023 at 11:33 PM Vinícius dos Santos Oliveira wrote:

Em seg., 2 de out. de 2023 às 11:49, Klemens Morgenstern via Boost escreveu:

...

On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost wrote:

...

I'm not going to submit a review but I do think the name is almost a misnomer.

The library is essentially just an Asio wrapper and isn't a genuine coroutine library.

What would be a genuine asynchronous coroutine library?

Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously).

asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too. So if I were to call std::coroutine_handle::resume() I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.

Racket does have preemptive fibers which are interrupted asynchronously (much like Golang's goroutines), but coroutines are not fibers. The Lisp community already learned this lesson:

...

The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well.

Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.

https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua

We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf

The least we should do is to at least take the time to listen.

I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism. I am pretty sure both had a different vision than what we got, and the dichotomy between fibers & coroutines in this paper arose from their idea of how to separate the concepts. .

Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines.

I am not familiar with ruby, but I reckon you'd consider goroutines to be fibers? The promise issue is why my library makes a distinction between an awaitable and a coroutine. It's not just syntactic sugar for promises, although I wonder why that would be a bad thing? What's wrong with using coroutines to get out of callback-hell? And I do agree with you, that coroutines are a wider topic, which is why my library is called async. I don't think it's the one true coroutine library, nor is it meant to be. Rather the idea is to allow it to interact with other coroutine libraries. For example, if you were to build a coroutine based stream parser you should be able to make it work asynchronously with an io stream based on boost.async.

So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated.

The coroutines you get with the async keyword in python or javascript, which means coroutines that run on a scheduler. Both languages have coroutines that are not async, too.

wt., 3 paź 2023 o 06:53 Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org> napisał(a):

Em seg., 2 de out. de 2023 às 13:23, Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> escreveu:

...

...

Can you explain to me what an asynchronous coroutine is? As far as I see, the context-switch always happens in well defined points/cooperatively (thus synchronously).

asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too.

I'm well aware of languages that perform free-style terming. And everybody mirrors NodeJS these days...

However the term there is short for “async IO” rather than async coroutines. In fact, coroutines don't even need to be marked as “async”. Chris Kohlhoff tried to persuade the C++ committee to adopt a keyword-less approach back in 2015: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf

Lua coroutines don't need such keywords either and are in fact more powerful (they can suspend the caller/parent) which makes it possible for them to implement fibers. Lua isn't the only language that exhibits this property. Same goes for Golang's goroutines.

Async means a lack of synchronization. You can combo the term with others to give it more meaning (e.g. async IO).

So if I were to call std::coroutine_handle::resume()

...

I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.

I like this example.

...

...

The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well.

Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.

That's correct. You followed the reasoning.

...

We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf

I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism.

Both concepts predate their Boost libraries counterpart (and C++20's as well). C++20 didn't invent coroutines.

It's easy to distinguish these concepts anyway. Fibers are meant as "lightweight threads" and as such any fiber library (Boost or not) will need to answer "what fiber should I *schedule* once current one can't make further progress?".

Coroutines are a generalization of subroutines that add two new operations: suspend and resume. You can dig into its history easily nowadays.

...

Communities such as Ruby do misnomer coroutines and fibers, but we shouldn't be learning from incorrect material. Just as much, there are plenty of communities for which coroutines are just a syntax sugar for promises, but then again: we shouldn't be learning from incorrect material. Coroutines are not syntax sugars for promise objects. Coroutines are a broader topic. The most popular implementation nowadays are promises objects, but beyond a function that resumes, all the other details that involve these promise objects have nothing to do with coroutines.

I am not familiar with ruby, but I reckon you'd consider goroutines to be fibers?

Not quite. If we want to be technically correct, goroutines are neither. Fibers come from threading terminology which is a concurrency model that competes against CSP (don't communicate by sharing memory; share memory by communicating). However fibers are closer to goroutines than coroutines. Both fibers and goroutines implicitly require a scheduler. Both represent the "unit of concurrency" in their own concurrency model.

Ruby is a weird "impure duck". I do like these pragmatic solutions (my own solution based on Lua and Boost.Asio mixes actors from the actor model and fibers). My dislike for Ruby is just in their minor misnomer here.

The promise issue is why my library makes a distinction between an

...

awaitable and a coroutine. It's not just syntactic sugar for promises, although I wonder why that would be a bad thing? What's wrong with using coroutines to get out of callback-hell?

...

And I do agree with you, that coroutines are a wider topic, which is why my library is called async. I don't think it's the one true coroutine library, nor is it meant to be.

Rather the idea is to allow it to interact with other coroutine libraries. For example, if you were to build a coroutine based stream parser you should be able to make it work asynchronously with an io stream based on boost.async.

Fair enough.

...

So, again, could you teach me what an asynchronous coroutine is? This is really a topic that I spend a lot of time mastering. Any new thing that I might learn here would be appreciated.

The coroutines you get with the async keyword in python or javascript, which means coroutines that run on a scheduler. Both languages have coroutines that are not async, too.

They happen asynchronously to what exactly? If there are asynchronous coroutines, there are synchronous coroutines. What distinguishes them? I never saw the term "asynchronous coroutines" anywhere before.

I just see a lack of rigorous analysis here. To be honest, if you just mirror the design of NodeJS or whatever, I can't acknowledge you as an expert in this domain.

What these languages really provide:

- An ecosystem of multiple independent concepts working together with proper synergy. - Among these concepts, a scheduler that concurrently (and synchronously, not asynchronously) switches between tasks. - Among these concepts, also an object to represent a task (a promise). - Also among these concepts, a coroutine at the language-level to remove the boilerplate of writing objects implementing the interface for a promise. - As an optimization when the host operating system provides (e.g. Windows IOCP, Linux io_uring) truly asynchronous IO support (a bigger topic that Boost.Asio already gets right).

I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time. It can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it that you'll offer for them to come here? They already have NodeJS. You need a differentiating factor.

I am convinced by this. If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy". Regards, &rzej;

-- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

niedz., 8 paź 2023 o 18:15 Vinnie Falco napisał(a):

On Sun, Oct 8, 2023 at 9:00 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".

I trust your judgement even though I am not completely familiar with the technical details of the argument presented.

That said, I believe that the review for this particular library is flawed, and I question the decision to accept.

There are an insufficient number of reviews, the scope of the library is not clear, and furthermore there is no clarity with respect to answering the question "what belongs in Boost?" Ask five different people on the list and you will get five different answers. If there is no documented explanation of what belongs in Boost then the outcomes of certain reviews are going to be highly unpredictable, especially those where there is controversy.

In some cases the answer to what belongs in Boost is obvious. Implementations of standard library features for older versions of C++ are an example of something that obviously belongs in Boost. A library modeled on an existing 3rd party library but polished up to Boost quality and working with other Boost libraries (e.g. boost::system::error_code) is another: Boost.JSON.

But then we have novel libraries for which reviewers have no template, no guidance, no existing practice to understand whether or not something belongs in Boost, and I believe Boost.Klemens.Async is the perfect example of such a library. This is my opinion, but I believe in these cases that the proper course of action is for the author to "do the work" of going out into the community and establishing a user base for the library before submitting it for review (as I have done with Beast and URL).

As an active member of the Official C++ Slack Workspace I observed the development process of Boost.Async, which unfolded roughly this way:

1. "Let's write a new library and propose it for Boost" 2. (work on library) 3. Propose for Boost

This can work when the author is a C++ savant like Peter Dimov but for ordinary humans such as myself I think that authoring a library with the intent of going "direct to Boost" is a recipe for yielding poor results. I believe that at a minimum we should have required some field experience before the review was scheduled, so that reviewers would have more information to go on in terms of seeing how this library fits into the Asio and coroutine ecosystem.

Andrzej: There is a process for disputing the results of a review, by reporting the concerns to the Review Wizard. I would like to dispute the review result, on the grounds mentioned above, and if you still feel strongly about rejecting the library for the aforementioned reasons then I suggest you also dispute the review results. This goes for everyone on the list. Who is the Review Wizard for this review?

Well, so far the results for this review have not been announced, so there is nothing to dispute. I had similar concerns for other libraries recently accepted to Boost: Boost.MySQL, Boost.Redis. I cannot assess their quality or design, as they are too big, and I am not an expert. They may be good, but even good libraries do not necessarily belong to Boost. Are they sufficiently general-purpose? Are we just giving a stump that a library meets a certain level of quality of design and implementation? Or are we aiming at an extended Standard Library? Regards, &rzej;

Side note: Did you know that review results can be disputed? Because I can't find this information on the website. I think we need to start documenting the review process and formalizing some of these common law rules, so that future reviews can be conducted at the high level of quality befitting Boost.

Thanks,

Vinnie

That said, I believe that the review for this particular library is flawed, and I question the decision to accept.

There are an insufficient number of reviews, the scope of the library is not clear, and furthermore there is no clarity with respect to answering the question "what belongs in Boost?" Ask five different people on the list and you will get five different answers. If there is no documented explanation of what belongs in Boost then the outcomes of certain reviews are going to be highly unpredictable, especially those where there is controversy.

Should I have rejected boost.url, which had the same amount of reviews? There are more libraries with seven or less reviews in boost, boost.lambda2 had 6. If we introduce a lower limit, Also, isn't a "REJECT, I don't think it belongs in boost" a fair review?

In some cases the answer to what belongs in Boost is obvious. Implementations of standard library features for older versions of C++ are an example of something that obviously belongs in Boost. A library modeled on an existing 3rd party library but polished up to Boost quality and working with other Boost libraries (e.g. boost::system::error_code) is another: Boost.JSON.

Why is the second obvious? I also find the question "does it belong in boost" misguided. If it passed review, it belongs in boost. You are free to write a short review rejecting it and the review manager is free to disregard

But then we have novel libraries for which reviewers have no template, no guidance, no existing practice to understand whether or not something belongs in Boost, and I believe Boost.Klemens.Async is the perfect example of such a library. This is my opinion, but I believe in these cases that the proper course of action is for the author to "do the work" of going out into the community and establishing a user base for the library before submitting it for review (as I have done with Beast and URL).

That's not really true. Libraries akin to async have been around in other languages for a very long time. Then there is also cppcoro and the coroutine types existing in asio. How big does the user-base need to be and how would this be measured?

Andrzej: There is a process for disputing the results of a review, by reporting the concerns to the Review Wizard. I would like to dispute the review result, on the grounds mentioned above, and if you still feel strongly about rejecting the library for the aforementioned reasons then I suggest you also dispute the review results. This goes for everyone on the list. Who is the Review Wizard for this review?

Which grounds? Too few reviews? Because all the other things you brought up should be addressed during review I would really like a review wizard to clarify what valid grounds for disputing a review are.

On Sun, Oct 8, 2023 at 3:37 PM Vinnie Falco wrote:

On Sun, Oct 8, 2023 at 1:26 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:

...

Should I have rejected boost.url, which had the same amount of reviews?

Perhaps, you could have, and it would not have bothered me in the slightest, because Boost.URL *already had users* and there were more coming every day. In other words Boost.URL offered such compelling usability and utility that it did not *need* to be part of the official Boost distribution in order for other projects

This got cut off, here is the full text: Perhaps, you could have, and it would not have bothered me in the slightest, because Boost.URL *already had users* and there were more coming every day. In other words Boost.URL offered such compelling usability and utility that it did not *need* to be part of the official Boost distribution in order for other projects to incorporate it and use it in informal and commercial projects. I want to be clear here, the practice of "we need to accept it into Boost to get users and find out if its any good" to be a harmful idea that carries significant reputational risk. There is no stated policy which describes whether or not this practice is valid for determining acceptance in a review, which is itself a problem (lack of a clear written instructions on how reviewers should evaluate libraries), and the reason that I am having to make these posts. It might be that such a policy would be detrimental as it would be too much of a hard and fast rule, and the question is best determined on a case by case bases. In that scenario I believe that Boost.Klemens.Async is one such case. Thanks

On Sun, Oct 8, 2023 at 4:42 PM Peter Dimov via Boost wrote:

Vinnie Falco wrote:

...

I want to be clear here, the practice of "we need to accept it into

Boost

...

to get users and find out if its any good" to be a harmful idea that carries significant reputational risk. There is no stated policy which describes whether or not this practice is valid for determining acceptance in a review, which is itself a problem (lack of a clear written instructions on how reviewers should evaluate libraries), and the reason that I am having to make these posts.

Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good.

Reviews from users count more than reviews from non-users, of course, but that's the extent of it.

As for "reputational risk", the reputation we have has been built while using the above policy.

I'm also thinking that we apparently need to have a (written) rule about people questioning the review result without having submitted a review. If you can't be bothered to invest the time to review the library, your opinion on whether it belongs in Boost doesn't count.

Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.

That said, it is still valid to express an opinion in principle. I don't feel qualified to write a review, but in principle I think it's valid to vote REJECT due to major design disagreements, as in "this is the wrong solution to the problem", however this requires at least outlining an alternative design. Other than that, if a library is well documented, solves problems reasonably well, and is written with competence and with domain knowledge, then it should be accepted.

On Sun, Oct 8, 2023 at 5:00 PM Vinnie Falco via Boost wrote:

On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost <

boost@lists.boost.org>

wrote:

...

Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good. ... Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.

What I am saying is that I believe the author knows the library would not get users on its own and this is why there was no effort to acquire them.

I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users. Authors who don't care about that don't bother with Boost, they go straight to std. :)

I challenge the author with this exhortation: get a user or two, show that this thing is compelling enough to be used outside of the Boost community in an actual project, and then submit it. What is so hard about that? What's the rush to put this into the collection? If it's good it will be just as good two or three releases from now. And no one will be impeded from using it even before it becomes part of a release.

... what makes you think I have zero users? Who are the people opening issues?

Klemens: why do you have zero users? The question is of course rhetorical because we already have the answers. No effort was made to acquire them, no thoughtfulness was put into actual user needs, no users were consulted during the development of the library. How many times was Peter Dimov consulted during the library's development? Did Christopher Kohloff offer his input?

I have users. I have talked to them and to potential users to refine the API & scope. You keep assuming the worst here and you're wrong on almost every point I did reach out to Peter & Chris as well, but neither led to any input. Now you're just making up things.

In the first review cycle for the library it was said that the library is single threaded and it made sense to optimize:

https://lists.boost.org/Archives/boost/2023/08/254938.php

I got no answer to this question so I asked it again:

https://lists.boost.org/Archives/boost//2023/08/254958.php

Still no answers to this question from August, the author provided no information about how the library is optimized, what kind of improvement was seen, the methodology for optimization, any kind of benchmarks, and so on. There is just a handwavey claim of performance. Is this how low Boost has fallen now? What happened to the engineering rigor and discipline that was the hallmark of Boost's heyday? Must we resign ourselves to the indignity of statements like "I don't see anything wrong with an author seeking acceptance in Boost as a way to acquire users?"

It didn't sound like a serious question - my docs have a benchmark section, you know? async uses symmetric transfer all over the place, which is the main optimization over asio. Using pmr is not really an optimization, but a customization point one can disable at compile time. I didn't want an allocator template parameter everywhere, so pmr is the standard version of achieving this. Beside symmetric transfer, async uses a small buffer in the coroutine frame which gets used for the associated allocator of an `co_await async_foo(..., use_op)` expression. Depending on the memory required by the op, that can mean that no allocations take place at all. The upstream of the sbo depends on whether or not PMR is disabled. See the "Operation Allocation": https://klemens.dev/async/benchmarks.html

Sad.

This thread is making me sad indeed.

On Sun, Oct 8, 2023 at 6:51 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:

I have users. I have talked to them and to potential users to refine the API & scope. You keep assuming the worst here and you're wrong on almost every point

If I am completely wrong about some of what I said or even all of it, then I am pleased and relieved. Thanks

On Mon, Oct 9, 2023 at 8:00 AM Vinnie Falco via Boost wrote:

On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost wrote:

...

Boost has never required a library to have users in order to be accepted. If the review process says it's good, it's good. ... Or stated differently, the proper and only way to express your opinion on whether the library belongs in Boost or not is by submitting a review.

What I am saying is that I believe the author knows the library would not get users on its own and this is why there was no effort to acquire them.

That's not the case. C++ desperately needs a library like this, and there's a reason cppcoro got very popular. I got 82 stars & 128 unique clones so far. The review and its announcement of course got some attention. I am probably excluding users by requiring boost, and could get more by making it optional. We surely disagree on that, but I obviously think my library is great and will attract users, especially younger ones that do not love callbacks as much as you. But you can be very sure, that I am absolutely confident that this library would get users without being in boost and I would urge you not to assume these kinds of motives.

On Mon, Oct 9, 2023 at 9:50 AM Vinnie Falco wrote:

On Sun, Oct 8, 2023 at 6:27 PM Klemens Morgenstern wrote:

...

...I obviously think my library is great and will attract users, especially younger ones that do not love callbacks as much as you.

Okay, that's fair. So in which places where callbacks are currently used, does this library offer the alternative?

All of them.

Thanks

...

But you can be very sure, that I am absolutely confident that this library would get users without being in boost and I would urge you not to assume these kinds of motives.

Why not get them then? Have you reached out to any of the forks? Do you have a channel where people outside the Boost community came to visit while you worked on the lib? Did you announce the development of the lib on Reddit so people could follow and weigh in? Did you find other projects that might benefit from using your library, and offer them a pull request where you integrate your library as an example to show them how it can be improved with your library? In other words was any there any effort placed into Boost.Klemens.Async other than the bare minimum of what is required to write a library which is to just sit down and over a continuous or intermittent period and simply write it unassisted and without input, and then submit it for a review?

Where do you get the unassisted from?

And let me ask you this, now that I have taken the time to elaborate in sufficient detail additional methodologies and markers of success which may be applied to library development, what do you think should be done with that information? Speaking for myself if I had done the same with one of my libraries, without going to reddit first, without announcing it first, without shopping it around to other projects to see what they think, without offering to integrate it, without constantly pestering Peter (or Chris, if he answered messages) for advice on how I can design my library to be better, and just carried on developing in a vacuum, then just collect it up and plop it down on the mailing list telling everyone else to review it and shove it into Boost because "we have to put it in Boost because it is great and young people don't like callbacks" - I don't think I would feel very good or proud about that.

Well, boost::asio::experimental::coro is the result of me pestering chris.

Now that I've said all that, does any of that resonate with you? Does it inspire you and make you want to do more, so your library can be the absolute best it can be? Is it too much work to do these things? Do you care about setting an example for others? Or perhaps you just know that your library is so great, that these things are not necessary, and want to signal to future potential library authors that if they, too, are confident that their library is "great and will attract users, especially young ones" that there is no need to push themselves to do more when more can be done.

It really depends on the library I would say. Boost.async came out of 2.5y or working with asio::awaitable and a bunch of workarounds like a `select` that were used by a five person team. Then I wrote asio::experimental::coro, which fulfilled a similar need, gets used and goes as far as that can within asio (with it's requirements). Add to that my experience with python & javascript and real world use cases of their async facilities Hence I feel confident in the design. If I just wrote async without any of the history before you would have a point. So I'd think it depends on the library, just like you said. Boost.json would have been fine to review without any users I reckon.

On Sun, Oct 8, 2023 at 7:21 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:

I kind of agree with Vinnie, no users, not enough tests. This is an alpha library and should come back when its place in the ecosystem has solidified.

I have to be fair though, the reality is that I cannot back up my claims with strong evidence and it is in fact based only on observation during the library's development of the repository and Slack interactions. So it is very possible that Klemens' is right and there is more to it than I am describing. This is one reason why I did not write a review. Another reason is that I am preoccupied with personal issues which prevent me from really investing a lot of time and energy into anything C++ related (including my own new libraries whose development is paused). Mainly what I am saying is that I believe there is/was room to do more to prepare the library for the review, and these things weren't done. The only reason I bring it up for Klemens' specifically is because I care more about him, as we have been working together for a while now. But this advice is not just for Klemens', if there is a new library with the intention to be proposed for Boost and it makes sense to do so, it is nice to see authors pull out all the stops and do everything in their power to make the library great even before the review. More docs, more tests, more exposition, more explanation, more benchmarks, more reddit posts, more users, more consultations, more... MORE.. you feel me? I want ordinary C++ users to feel shock and awe at the level of preparation and attention to detail that goes into new library submissions. I want them to be inspired. To aspire to become more like Boost authors. Thanks

On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost wrote:

...

This is an alpha library and should come back when its >place in the ecosystem has solidified.

I disagree because this restriction was not required in the past. It seems to me unfair to make it mandatory now.

I am using Oliver's comment to add my own. Klemens obviously has a good amount of stars and forks, which signals interest from the community, so he does not need me to defend his proposal. But I also want to give my option on "should libraries proposed for adoption have many users already?". Whether or not a library has a lot of users before submission is fairly irrelevant. It can be a point in favour, but does not have to be. It may address the question "is this library useful"? but does not tell whether the library is well designed. Some people need a lot of user feedback to refine the design, others are good internal critics and can improve without external feedback. Both are valid approaches to design and suit different people. Obviously, everyone needs some external feedback, but it is quality and not quantity that matters. Also, we all know from politics and examples in tech, that popularity is not always a good measure of quality. Usefulness, design, quality, etc are judged by the reviewers. I have high confidence in the Boost reviewers to make this assessment. Users do not get to vote on acceptance, Boost members do. Boost is a meritocracy, not a democracy.

On 09/10/2023 16:01, John Maddock via Boost wrote:

On 09/10/2023 10:12, Hans Dembinski via Boost wrote:

...

...

On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost wrote:

...

This is an alpha library and should come back when its >place in the ecosystem has solidified. I disagree because this restriction was not required in the past. It seems to me unfair to make it mandatory now. I am using Oliver's comment to add my own.

Klemens obviously has a good amount of stars and forks, which signals interest from the community, so he does not need me to defend his proposal. But I also want to give my option on "should libraries proposed for adoption have many users already?".

Whether or not a library has a lot of users before submission is fairly irrelevant. It can be a point in favour, but does not have to be. It may address the question "is this library useful"? but does not tell whether the library is well designed. Some people need a lot of user feedback to refine the design, others are good internal critics and can improve without external feedback. Both are valid approaches to design and suit different people. Obviously, everyone needs some external feedback, but it is quality and not quantity that matters.

Also, we all know from politics and examples in tech, that popularity is not always a good measure of quality.

Usefulness, design, quality, etc are judged by the reviewers. I have high confidence in the Boost reviewers to make this assessment. Users do not get to vote on acceptance, Boost members do. Boost is a meritocracy, not a democracy.

+1.  Also just to add to that, existing libraries with wide user bases come with a legacy that may may it harder for them to make radical improvements to the user interface should that be required.  On the other hand brilliant interface design with no user experience also carries it's risks.  This is what reviews are for, to balance all this up, and it's good to see some discussion being generated again.

It's also worth pointing out that Boost when founded was a place for radical bleeding edge design and experimentation, I see no reason for it not still be so as long as such libraries are well documented as such.

With apologies, I'll now go back to lurking again, as I have no knowledge of the problem domain...

Ah nothing like lots of post-review discussion to make the writing of the review report easier! (Apologies for replying to your reply John, yours was just the latest in the chain which is why I chose it) Firstly, I hope to complete writing the review conditions and report this Wednesday. I won't promise it, I set aside last Wednesday morning and then stuff came up and it didn't end up happening. But I'll keep retrying until I get it done. I apologise for the delay, I am doing my best. Secondly, please do not challenge the review until I've actually published the review conditions and report. This particular review currently has three major conditions in my draft report, and it may gain more before I'm done. If after its publishing then people feel it was a bad review, rock on with lodging challenges. Thirdly, I have no idea why Boost has become so conservative about new libraries recently. There is a long and proud tradition of Boost publishing crazy new libraries that so pushed the state of the art they didn't even compile on ANY compiler bar one compiled from trunk. They certainly by definition had ZERO users. We also used to - once upon a time - be comfortable with publishing a library, finding out after users complained it was badly flawed, so then we made a v2 of that library with all those problems fixed and quietly deprecated/discouraged the further use of the v1 library. And whilst not ideal, that's exactly how states of the art get pushed. Sure, it would be even better if a library had lots of users first, but there can be a chicken and egg problem for particularly radical libraries - until somebody solves a problem, nobody realises that that problem should be solved that way. Right now C++ coroutines have a bad rep in the C++ userbase, and they are currently quite unpopular as we saw from the Reddit reaction to the announcement of the review of this library. However that won't last, eventually the userbase will warm to using them where they solve well what they're good at solving well, and more importantly, not using them to solve what coroutines solve elsewhere, because C++ coroutines != coroutines elsewhere. I don't know if when people warm up to C++ coroutines they'll reach for proposed Boost.Async. If they do not, an equally beneficial outcome for Boost and/or the C++ ecosystem is if they make a new C++ coroutine library which incorporates the ideas from proposed Boost.Async but iterates on them. And if that happens, Boost will have enabled that, which is exactly what Boost is supposed to do. In this I'm seeing lots of upsides across the board. I also disagree that Boost gets hurt by experimental libraries which don't work out. Nobody using Boost will ever be forced to use proposed Boost.Async. If it doesn't work out, it will have literally zero negative effect on Boost users apart from a slightly longer download time. In my opinion, a much more likely outcome is that accepting new experimental libraries make watching Boost a must to see what comes. Most of the lurkers on here are here precisely because Boost can be a weather vane onto the future of C++. More experimental libraries makes Boost more relevant in my opinion, even if some will fail to gain traction. Without taking a risk, we would never know. Speaking personally, C++ coroutine programming is tedious and annoying with the current C++ coroutine library frameworks. Proposed Boost.Async restores much of the fun and joy in writing C++, albeit with tradeoffs, but nothing comes for free. At my last job we had a set of custom completion tokens for ASIO which implemented a very similar solution to proposed Boost.ASIO. At my current job I just finished up last week C++ coroutine support which - surprise surprise - looks awfully like proposed Boost.Async again (except these are based on io_uring and use Niall's "much improved" Sender-Receiver design which WG21 rejected). I think there are only a very few of us with sufficient domain expertise in this area to be able to judge whether proposed Boost.Async is a solid generalised solution to this problem domain. I don't claim to be one of them, but having implemented something similar twice now, and having been "in the room" throughout WG21's labours on Sender-Receiver and ASIO, even though WG21 rejected almost everything I said or proposed I would like to think I am less misguided than they are :) Even if I am very misguided, I think accepting this library is worth the punt. It'll be an accept with conditions, and the report will be long as there will be a short list of binding conditions and a long list of non-binding conditions. I'll get it to you all when I can. Niall

On 09/10/2023 18:00, Vinnie Falco wrote:

On Mon, Oct 9, 2023 at 9:57 AM Niall Douglas via Boost mailto:boost@lists.boost.org> wrote:

Ah nothing like lots of post-review discussion to make the writing of the review report easier!

Thank you for your well thought-out message. There are some good points there. I do wish that there was more documentation and wisdom collated from mailing lists posts regarding the review process. You brought up a lot of informal guide rails, why aren't we committing this to an asciidoc document on the website?

As with everything Boost, I would guess nobody has to date sat down and written out the documentation? I think I was the last person to substantially refactor the documentation page on the review process? The one before I did that had been there for years, didn't actually match the review process, and everybody here agreed it needed fixing but nobody had stepped up to do it. I did at the time, after a few people here checked my new text now matched reality (at that time) it was merged and to my best knowledge, nobody has substantially improved upon those docs since then. And that was many years ago now. Documentation can always be improved of course, but getting the right people to do it is always the hard part. Niall

Sent from my iPad

On 9 Oct 2023, at 06:21, Christian Mazakas via Boost wrote:

It's quite a stretch to say C++ desperately needs Async. I've shipped C++ apps using Asio and I can safely say I've never desperately needed a library like this.

I kind of agree with Vinnie, no users, not enough tests. This is an alpha library and should come back when its place in the ecosystem has solidified.

“No users” is a false assertion.

- Christian

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

I did learn from NodeJS and it was good at the time as it helped to push people for something better. However I also learnt from Boost.Asio, Boost.Coroutine, Boost.Context, Boost.Asio, and plenty of members inside and outside Boost's community. Honestly, NodeJS just got stuck in time. It can't hope to grow more than it already did. If you provide a complete copy of NodeJS inside C++ so NodeJS programmers can come over, what is it that you'll offer for them to come here? They already have NodeJS. You need a differentiating factor.

I am convinced by this.

You shouldn't be, because this is not an accurate description of my library.

If I were reviewing the library now, after what I have learned from this thread, my recommendation would have been to reject the library for now, as it was the case when Boost was young, on the grounds that the programming model and the scope is not clear. It is still not clear to me, "when I should use this library". My best approximation is "when I already use Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too clumsy".

Can you elaborate on what changed your mind exactly? Libraries like this need a scheduler, boost.fiber has one, too. In the case of boost.fiber it's much more elaborate, which I don't consider necessary for async. Hence it just uses a generic scheduler that's already in boost: boost::asio::any_io_executor. A nice side effect of that is that users CAN use asio directly with that on a single thread, but that's not a necessity. They can also plugin their own awaitables, that have nothing to do with asio. I got two examples of that 1. co-awaiting a boost.signal2 https://github.com/klemens-morgenstern/async/blob/master/example/signals.cpp 2. co-awaiting an spsc-queue https://github.com/klemens-morgenstern/async/blob/master/example/spsc.cpp The latter does use two functions from the asio namespace, that should probably be pulled into the async namespace. Note that both functions are related to boost::asio::any_io_executor. Now, let's say you got five threads producing values and pushing them out into an spsc-queue. So you got five event sources that now need to feed a state machine. You can model that with async and since the co-await will already make sure that all is running on a single thread, it'll be much easier to write & maintain. I hope that makes sense.

Am 02.10.2023 um 18:23 schrieb Klemens Morgenstern via Boost:

...

What would be a genuine asynchronous coroutine library? asynchronous in my lingo means that the coroutine might suspend to an asynchronous event source, e.g. a timer expiring. This is my lingo, but is how other languages that provide an async keyword do it, too.

So if I were to call std::coroutine_handle::resume() I can't assume it's done (reached a yield or a return) when resume returns. This is different from a synchronous coroutine like std::generator, where the .resume() will only occur after a value has been yielded or the generator returned.

There is a difference between asymmetric/symmetric coroutine-like control-transfer - see 'P0876: fiber_context - fibers without scheduler'.

...

Racket does have preemptive fibers which are interrupted asynchronously (much like Golang's goroutines), but coroutines are not fibers. The Lisp community already learned this lesson:

...

The difference between a fibers facility and just coroutines is that with fibers, you have a scheduler as well. Well, then what I call an async coroutine, is a conceptual fiber implemented via coroutines. I say conceptual, because boost.fiber and the paper you cite below use an entirely different API from what my coroutines do.

There are two kinds of coroutine-like operations - stackful and stackless ops. The C++-20 coroutines are stackless (not realy because some memory has to be allocated to hold the local variables that would usally be stored in the stack frame). The other C++ coroutine-like stackful option has been named 'fiber' by the C++ standards committee (proposal P0876: fiber_context - fibers without scheduler). (C++)-Fibers are asymmetric stackful coroutines implemented by boost.context that do not require a scheduler. boost.fiber is a library using the C++-fibers from boost.context and implements a kind of userland threads (including a scheduler).

...

https://wingolog.org/archives/2018/05/16/lightweight-concurrency-in-lua

We have some of the best experts in this domain in our own community, and a few of them spared the time just on this topic as well:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf

The least we should do is to at least take the time to listen. I would like to point out that the paper does compare the author's coroutine paper to their fiber paper. It does not compare fibers (since it was written in 2014) to the coroutines standardized in C++20, and thus also provide no await mechanism.

I am pretty sure both had a different vision than what we got, and the dichotomy between fibers & coroutines in this paper arose from their idea of how to separate the concepts.

The paper is deprecated in vafour of P0876. As mentioned above - you have to distinguish between stackless/stackful and symmetric/asymmetric control flow (as described in P0876). Oliver

On 02/10/2023 17:18, Vinnie Falco wrote:

On Mon, Oct 2, 2023 at 7:40 AM Niall Douglas via Boost wrote:

...

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?

I don't like it at all and I agree with the "land grab" concern. I was hoping this library would be rejected and the naming would be a non-issue. There were only what, 2 reviews?

I believe the current count is six reviews, and two sets of detailed notes which are most of a review each. More than enough. All recommend acceptance incidentally. My work will be to condense the conditions into a feasible set for Klemens to work upon. I see no current reason why it won't be an accept, just with conditions. It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?

...

If you are not, please suggest a preferred alternative name.

Certainly, the naming of a library plays a significant role in its perception and utility. Here are ten alternative names that aim to be specific and descriptive, while avoiding a "land grab":

Boost.Coroutinify Boost.Asiotasker Boost.CoAsio Boost.Yielder Boost.AwaitIO Boost.AsioGen Boost.FiberAsync Boost.Eventuals Boost.TaskifyAsio Boost.CoroutineX

Choosing a name that resonates with both the functionality and the ethos of the library can be a delightful challenge. Happy coding!

---

The ChatGPT-4 prompt which produced the above:

A boost library is proposed which is based on Boost.Asio and C++20 coroutines, and calls itself Boost.Async because it provides generators, tasks, and promises to facilitate coroutine implementations. A reviewer has raised the concern that the name Boost.Async constitutes a naming "Land grab" as it is too generic. Propose 10 other names for this library which are not generic.

Clever GPT. Niall

pon., 2 paź 2023 o 18:51 Vinnie Falco via Boost napisał(a):

On Mon, Oct 2, 2023 at 9:30 AM Niall Douglas via Boost wrote:

...

It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?

I don't have enough knowledge or experience with C++20 coroutines to be able to write a solid review but I believe there is a pattern of hastily written libraries being proposed for Boost which have reasonable implementations but not well thought out designs or extensive field testing. I am also concerned that coroutines are "in style" and there is a tendency for less seasoned reviewers to rubber-stamp anything related to them. However I lack sufficient evidence to lay this all out in a thoughtful way and thus I remain silent. If this library is accepted we might consider it an experiment to see if my concerns are needless. And allow sufficient time to pass before we review another hastily written library.

Thanks for saying this Vinnie. I share the concern. I disagree with your decision, though, to refrain from the review because you think you lack domain knowledge. This is what the review question "how knowledgeable are you in the problem domain" is for. I fit into your description of a "less seasoned reviewer", so I just mention this in the review, and still make my contribution. This works as long as the reviews are not treated as votes. Regards, &rzej;

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 02/10/2023 20:24, Andrzej Krzemienski wrote:

I believe the current count is six reviews, and two sets of detailed notes which are most of a review each. More than enough.

All recommend acceptance incidentally. My work will be to condense the conditions into a feasible set for Klemens to work upon.

I see no current reason why it won't be an accept, just with conditions.

I know that you know it, but let me still reiterate here the rules of the Boost Review process for the benefit of all the people reading this list. The review manager makes the decision whether to accept or reject the library based on their discretion. The recommendations from the reviewers are only means to help guide this decision. No democracy or averaging of the reviews is at play.

Very true. However, as I've often said in the past, the review feedback is in my opinion much more valuable than getting a library in or not. High quality feedback on software design is rare and valuable in any context, Boost remains a uniquely high quality source of such feedback. Speaking more widely, I've now had one REJECT review, and a few more expressing negativity about the design and naming. This will make it interesting trying to write a useful summary. I hope to get the review summary written and posted for the end of this week. Non-work life is busy, I built half a solar panel array last weekend (and my muscles remain very sore from it), and non-work time this week is mostly going into visiting glazing showrooms. I'll see if I can find a few hours to collate the reviews. Niall

On Mon, Oct 2, 2023, 18:31 Vinnie Falco via Boost wrote:

On Mon, Oct 2, 2023 at 9:18 AM Vinnie Falco wrote:

...

If you are not, please suggest a preferred alternative name.

Twenty more:

Boost.CoroMate Boost.AsioWave Boost.AsyncFusion Boost.PromiseIO Boost.AsioFlow Boost.Awaitables Boost.CoroutineSphere Boost.GenTasks Boost.IOPromise Boost.ASyncor Boost.EvolveAsync Boost.Corollary Boost.AwaitSphere Boost.TaskWave Boost.CoroutineCraft Boost.AsyncNest Boost.AwaitFusion Boost.CoRoutineHub Boost.Genio (Generator + Asio) Boost.ElasticAsync

Boost.Awaitables? Regards, &rzej;

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 10/2/23 11:26 AM, Richard Hodges via Boost wrote:

I miss the days when libraries and useful programs are given terse names that were fun and easy to remember.

biff, mutt, vi, sed etc spring to mind.

I certainly don't. As my memory deteriorates, I'm less enamored with cleverness for it's own sake than I used to be. e.g. I have no idea what mutt and etc are.

...

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Well, if we're going for fun, then i dare to propose Boost.ACE, which would stand for Asio Coroutine Extensions.

Well that I could live with.

That being said, the doc misses a requirements section. I'm still not sure if asio is a strict requirement or not.

It is a hard dependency, because writing my own scheduler seemed unreasonable. I'll add a requiremenst section (https://github.com/klemens-morgenstern/async/issues/126).

Regards,

Julien

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Tue, Oct 3, 2023 at 3:35 PM Bjørn Roald wrote:

On 3 Oct 2023, at 09:04, Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:

Well, if we're going for fun, then i dare to propose Boost.ACE, which would stand for Asio Coroutine Extensions.

Well that name may work, but it is sort of a throw-off for me as I am old enough to know about the Adaptive Communication Environment (ACE):

The ADAPTIVE Communication Environment (ACE) https://www.dre.vanderbilt.edu/~schmidt/ACE.html dre.vanderbilt.edu https://www.dre.vanderbilt.edu/~schmidt/ACE.html [image: favicon.ico] https://www.dre.vanderbilt.edu/~schmidt/ACE.html https://www.dre.vanderbilt.edu/~schmidt/ACE.html

As ACE address related in problem domains, and as it still is live and kicking in its own corners of the C++ world, such a name choice begs the question of what the relation is. So for what it is worth, to me that name is taken to mean something else. Sorry.

Absolutely fair point. This is why naming is hard. And for me `async` is associated with the async keyword in other languages, that do something quite similar.

Also, without having had time to review the proposed Boost.Async as closely as I would like to form an opinion on acceptance. I have read the docs and I was really hoping the ASIO dependency was more of a backend issue in need of executors. If so, adding ASIO in its name is perhaps a poor choice.

It is. asio's any_io_executor is a pretty good polymorphic executor, that can run on any event loop (e.g. Qt). I even have an example in async which is using python's asyncio event loop instead of asio's. I think many users remember the early days of asio, when everything was directly dependent on asio's io_context and thus think my dependency means you'll get all of asio included. A lot has happened, and asio contains the proposed standard executors, which is the part async is depending on.

— Bjørn

On Mon, Oct 2, 2023 at 11:18 AM Christian Mazakas via Boost wrote:

I'd be curious if it gains any real users by being included in Boost and who knows, maybe people will actually like it..

I have mixed feelings about this. One the one hand Boost is supposed to be slightly more relaxed than LEWG with respect to new additions to the collection. But in my opinion, the acceptance of this library is effectively saying to the public that the Boost community of reviewers believes the public interface and intended use-case of the library follows what we believe to be best practices and state of the art for C++ coroutines. Is it, however? I don't know, as I am not a subject matter expert, but I don't think that accepting to answer that question just by "shoving it into Boost" is healthy. Boost.Beast, Boost.JSON, Boost.URL all had users outside the Boost community well before any reviews took place. I would argue that Boost.JSON was so similar to previous popular works that it wasn't that meaningful but Beast and URL are sufficiently novel in their public interfaces that it could not and should not have been taken for granted that they should be accepted without some users. Not all Boost libraries need this, only some. For example Boost.Charconv is essentially already vetted since it is based on an established API. I don't speak for Boost and I am relatively new compared to some folks that have been around from the beginning, so I am unsure whether my criteria about seeing some field experience for this particular library is important. Perhaps someone who has been involved in Boost longer than me and is more familiar with the unwritten rules of the review process can offer clarity on this point.

It's not too late for a review from you or Richard if you have strong feelings that the library ought to be rejected?

I do not believe I have sufficient emotional, mental, and technical resources to write a review for this library at a level of quality that represents Boost's reputation and the interests of the invested parties fairly. All I have are these thoughts, which are not sufficient to arrive at a simple accept or reject conclusion. Other people will need to decide if and what importance to place on it. I'm okay with any outcome. Thanks

On Tue, Oct 3, 2023 at 5:06 AM Alan de Freitas via Boost wrote:

I completely share this concern. Even Asio claims to be "Async I/O" with its name, which is less specific than "Async 'Anything'". And this library is more specific than Asio. Not more generic.

If I saw some library named "Async" on github, I wouldn't be expecting only Async I/O.

Well, my idea is to have more libraries in the future, e.g. async.gpu or async.http, and hopefully not only written by me personally. The current async is essentially supposed to be async.core if you will. I actually would like to have an async.io library too, that simplifies using sockets and papes and would be an actual asio wrapper.

I'd be expecting introductory examples showing me how to calculate π using my GPU the best it can without any references to coroutines or I/O, which would be optional. Or how to train my AI model using a GPU cluster. Or how to optimize a function using all of my computer's processing power. *And* some examples involving I/O. It wouldn't have that single-thread limitation, either. Even if it's a bad idea for some use cases because the branding makes a promise to cover all cases.

Does it? The limitation is that multi-threading must be explicit, i.e. you can't co_await accross threads. But you can use spawn & async::thread to do cross threads. You basically already have an async.thread minimodule, which could have additional utilities for multi-threading.

To be clear, the limitation might be OK because it's justified for the use case. Only the relationship with the name seems problematic. Also to be clear, I'm not saying we need these libraries to help me work with GPUs.

I don't have a good alternative because identifying a problem with a name is much easier than coming up with good names, let alone good names that Klemens would like. But I can say I like names like Boost.CoAsio better than Boost.Async. It clearly describes that it's about coroutine extensions for Asio.

I don't like asio in the name. async is using asio, yes, but that's because it needs an event loop & cancellation. asio provides a polymorphic executor (which you can use with anything really) so it would be stupid to throw that away and prevent users from using all the asio and asio-based libraries just to be pure. But conceptually async relies on what were the Proposed Standard Executors (https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/std_executors.html) and the cancellation Slots Chris added since (the latter could be replaced by a custom implementation without issues - there just isn't a reason to do so). Async provides seamless integration into the rest of asio through use_op. So I don't think categorizing async as an asio extension or wrapper is entirely accurate. But I get it, asio is so huge these days, it should maybe be more than one library. Regarding other names (let's say co_async): Let's say we build a boost.async based sql library? Isn't boost.async.sql much better than boost.co_asio.sql ? or should that be boost.co_sql? I thought that we could have boost.async.sql here. Especially since the already existing asio based libraries (beast, mysql, redis) Neither use async nor asio in their name. I get it's a bit of a generic name, but it's hardly a land grab. This is homesteading.

And we do need some Asio extensions because Asio involves lots of concepts and their concrete implementations don't always fit in Boost.Asio or Boost.Beast.

Am 03.10.2023 um 07:52 schrieb Klemens Morgenstern via Boost:

1. ASYNC

The name async is meant to homestead the async name for sure, so we can have other coroutine based modules like async.io, async.http (hopefully working with a future http-proto) and async.mysql etc. This is based on other languages using `async` as a keyword.

The asio-based libraries in boost at this moment are beast, mysql & redis. None of those have asio in their name. Redis was aedis, to clarify it's async, but I thought this was bad for searches and proposed Marcelo to change it. That combined with the fact that no one has yet claimed async, made it seem like a good choice, especially if we can have simplified apis for the already existing asio-compatible libraries as async.redis and async.mysql, maybe a low-level io library, called async.io and async.process. That is, the name boost.async would mean C++20 coroutines based. I am unsure if the criticism of the name is that it implies too much (i.e. it should include the above-mentioned modules already) or if it implies to be something different (like a generic async completion solution, akin to asio's completion tokens). If it is the former, this library is probably boost.async.core. Which would be an alright name, but I would expect for all the types to still be in the boost::async namespace, so I don't see the point. +1 An alternative I am not too fond of would be to use the `co_` prefix, as it is the prefix of the coroutine keywords, e.g. making this library `co_async` or just `co`. Then other coroutine libraries could be `co_mysql` etc. I would also like to note that other good names are already taken, such as boost.coroutine. And naming this library boost.coro or something would be much worse than async, because it's ambiguous and would also promise too much.

+1

2. TASK/PROMISE

The solution Niall opted for is eager & lazy. I don't like adjectives as class names (similarly I don't like asio::awaitable) because that's a property of a thing. So imo they should be concepts or traits (e.g. is_eager), which is the case with async::awaitable. +1 boost.context uses "fiber" for the lazy and "continuation" for the eager types. Which makes sense, but `contiunation<T>` would look off to me, because it doesn't continue a T.

boost.context uses 'fiber_context' as requested by the C++ standards committee (proposal P0876: fiber_context - fibers without scheduler). It provides an asymmetric, stackful coroutine-like operation - in contrast to this C++20-coroutines are symmetric and stackless. boost.context provides an additonal API `callcc/continuation' (call-with-current-continuation) - it is based on the Scheme call/cc and is deprecated. The `continuation< T >`is a suspended stack with preserved registers. Oliver

Klemens Morgenstern wrote:

That is, the name boost.async would mean C++20 coroutines based.

You can use something more abstract such as boost::co20.

On Tuesday, October 3, 2023, Christian Mazakas wrote:

I emphatically support the name ACE or just Ace for this library

Not so great for those of us who remember the original ACE C++ libraries: http://www.dre.vanderbilt.edu/~schmidt/ACE.html Glen

On Tue, Oct 3, 2023, 10:14 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:

I emphatically support the name ACE or just Ace for this library as: Asio Coroutine Extensions.

This perfectly describes the library and is a nice short name that's unique and pops.

One thing I don't understand, the authors insists that Asio is just here for its event loop and cancellation but if you look at the docs, like 80% of Ace's interface contains `boost::asio::` in it.

Those two statements are unrelated. 80% of things just need an event loop and cancellation support. I also wanted to mention that I think I saw a signature that accepted

`io_context::executor` when it should just be `asio::any_executor`.

Which function was that?

This seems to be based on the notion that Asio's executors will someday make it into the standard but that ship has already sailed and no matter what we think, Sender/Receiver are most likely going to be the future of execution in standard C++.

I dont think we will get either standardized. Until i am proven wrong, asio is the best pick for an event loop.

I think, in general, Ace should attempt to hide as much of Asio as it physically can. Right now, this library exists in an odd middleground.

Why? Why is hiding things an ideal?

It's too entrenched in Asio for non-Asio users to really use and if you are an Asio user, Chris is already implementing like 90% of the proposed functionality here in its experimental namespace.

In which way is this too entrenched? Please provide some specifics. The only thing that supports symmetric transfer in asio is the experimental::coro. Nothing else, so all synchronization utilities must go through an executor.

- Christian

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost