[boost] [Async] Naming land grab?
Niall Douglas via Boost
I have received a non-public review which raises concerns about the
naming land grab by proposed Boost.Async i.e. a Boost library called
"Async" claims too much through its name.
Seeing as nobody here has raised this concern to date, can I confirm
everybody here is fine with proposed Boost.Async being called Boost.Async?
If you are not, please suggest a preferred alternative name.
Niall
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Christian Mazakas via Boost
The library is essentially just an Asio wrapper and isn't a genuine
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.
I agree with having the library being renamed.
- Christian
Klemens Morgenstern via Boost
<bo...@lists.boost.org> 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?
Vinícius dos Santos Oliveira via Boost
bo...@lists.boost.org> escreveu:
> On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost
> <bo...@lists.boost.org> 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).
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.
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.
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.
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.
--
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
Vinnie Falco via Boost
<bo...@lists.boost.org> 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?
> 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.
Thanks
Klemens Morgenstern via Boost
<vini.i...@gmail.com> wrote:
>
> Em seg., 2 de out. de 2023 às 11:49, Klemens Morgenstern via Boost <bo...@lists.boost.org> escreveu:
>>
>> On Mon, Oct 2, 2023 at 10:43 PM Christian Mazakas via Boost
>> <bo...@lists.boost.org> 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<some_async_coro>::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.
Niall Douglas via Boost
> On Mon, Oct 2, 2023 at 7:40 AM Niall Douglas via Boost
> <bo...@lists.boost.org> 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
Vinnie Falco via Boost
> 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
Vinnie Falco via Boost
<bo...@lists.boost.org> 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
Phil Endecott via Boost
> I have received a non-public review which raises concerns about the
> naming land grab by proposed Boost.Async i.e. a Boost library called
> "Async" claims too much through its name.
>
> Seeing as nobody here has raised this concern to date, can I confirm
> everybody here is fine with proposed Boost.Async being called Boost.Async?
>
> If you are not, please suggest a preferred alternative name.
>
> Niall
I'd make a similar argument for other libraries that are highly dependent
on ASIO.
Regards, Phil.
Christian Mazakas via Boost
When I saw on slack that when someone tried an early version of Async
and it immediately segfaulted when trying to do a client SSL
handshake, I realized the library has seen exactly zero production
usage by any real financial stakeholders.
I agree with Vinnie's assessment that the library seems hastily
written and I'd call it under-tested. Or at least, it was then.
Note, I don't call it a coroutine library because it doesn't contain
any primitives one would use to write a runtime. Instead, it _is_ a
runtime which is something different altogether. Even worse, it's an
opinionated runtime favoring I/O workloads and it brings conditional
dependencies on Container which I feel ultimately harms it.
I haven't formalized my rejection but in similar thoughts as Vinnie's,
I'm not opposed to acceptance because I'd be curious if it gains any
real users by being included in Boost and who knows, maybe people will
actually like it.
Note, I've shipped applications written in Asio and I'm also the
author of my own coroutine I/O runtime built on top of io_uring so I
know both domains well. I don't see much of an onus to ever use Async
over Asio but clearly other Asio users do so I'd be curious to see how
this library fares.
- Christian
Andrzej Krzemienski via Boost
wrote:
> On Mon, Oct 2, 2023 at 9:18 AM Vinnie Falco <vinnie...@gmail.com>
> 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;
Richard Hodges via Boost
wrote:
> On Mon, Oct 2, 2023 at 9:18 AM Vinnie Falco <vinnie...@gmail.com>
> 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
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.
Andrzej Krzemienski via Boost
napisał(a):
> On 02/10/2023 17:18, Vinnie Falco wrote:
> > On Mon, Oct 2, 2023 at 7:40 AM Niall Douglas via Boost
> > <bo...@lists.boost.org> 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.
>
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.
For instance, I mentioned in the review that I have a superficial knowledge
of the C++ coroutines, and I expect my recommendation to be weighed
accordingly.
Regards,
&rzej;
Andrzej Krzemienski via Boost
napisał(a):
> On Mon, Oct 2, 2023 at 9:30 AM Niall Douglas via Boost
> <bo...@lists.boost.org> 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;
Niall Douglas via Boost
> 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.
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.
Robert Ramey via Boost
>
> 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.
cleverness for it's own sake than I used to be. e.g. I have no idea what
mutt and etc are.
Alan de Freitas via Boost
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.
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.
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.
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.
Em seg., 2 de out. de 2023 às 11:39, Niall Douglas via Boost <
bo...@lists.boost.org> escreveu:
--
Alan Freitas
https://alandefreitas.github.io/alandefreitas/
<https://github.com/alandefreitas>
Vinnie Falco via Boost
<bo...@lists.boost.org> wrote:
> I'd be curious if it gains any real users by being included in Boost
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
Klemens Morgenstern via Boost
<bo...@lists.boost.org> 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.
>
_______________________________________________
Vinícius dos Santos Oliveira via Boost
klemensdavi...@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<some_async_coro>::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.
--
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
_______________________________________________
Vinícius dos Santos Oliveira via Boost
bo...@lists.boost.org> escreveu:
> 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
>
I like the name AwaitIO for what Klemens had developed. FiberAsync is
definitely a no.
--
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
_______________________________________________
Klemens Morgenstern via Boost
<bo...@lists.boost.org> wrote:
>
> Dear Boost,
>
> I have received a non-public review which raises concerns about the
> naming land grab by proposed Boost.Async i.e. a Boost library called
> "Async" claims too much through its name.
>
I wrote a few things in responses and thought it might be good to
summarize my thoughts here, as not everyone will read through lengthy
discussions.
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.
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.
Also note that there is nothing related to IO in this library itself.
2. TASK/PROMISE
Since we're bikeshedding already, I might as well throw in the names
task & promise which came up during review.
It might be cultural, but the implied eager & laziness is obvious to
me. Tasks get scheduled, promises should get fulfilled without
scheduling. E.g. if you lend me your drill and I promise to return it,
that should happen without you asking (i.e. co_awaiting) it. If you
give a company the task to paint your fence, you'd expect that to be
scheduled. There is of course an issue with promise, as the internal
coroutine state is using the same name.
The std::packaged_task is a way to create a lazy future. std::promise
is the way to create a lazy future, it's just callback based.
std::future thus can be both, lazy or eager, depending how it was
created. Which is why I opted not to use it.
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.
This could of course be because my native language, german, is big on nouns.
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.
Oliver Kowalke via Boost
Am 02.10.2023 um 18:23 schrieb Klemens Morgenstern via Boost:
>
>> What would be a genuine asynchronous coroutine library?
> 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<some_async_coro>::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.
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.
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.
As mentioned above - you have to distinguish between stackless/stackful
and symmetric/asymmetric control flow (as described in P0876).
Oliver
Julien Blanc via Boost
écrit :
> On Mon, 2 Oct 2023 at 18:31, Vinnie Falco via Boost
> <bo...@lists.boost.org>
> 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.
Well, if we're going for fun, then i dare to propose Boost.ACE, which
would stand for Asio Coroutine Extensions.
That being said, the doc misses a requirements section. I'm still not
sure if asio is a strict requirement or not.
Regards,
Julien
Oliver Kowalke 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.
> 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.
> 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.
> eager types. Which makes sense, but `contiunation<T>` would look off
> to me, because it doesn't continue a T.
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 via Boost
> would stand for Asio Coroutine Extensions.
>
> That being said, the doc misses a requirements section. I'm still not
> sure if asio is a strict requirement or not.
I'll add a requiremenst section
(https://github.com/klemens-morgenstern/async/issues/126).
Niall Douglas via Boost
> 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.
`boost::outcome::awaitables::eager<T>`
`boost::outcome::awaitables::lazy<T>`
The enclosing namespace `awaitables` I think is rather important to the
naming choices of "eager" and "lazy".
Niall
Bjørn Roald via Boost
> On 3 Oct 2023, at 09:04, Klemens Morgenstern via Boost <bo...@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):
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.
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.
—
Bjørn
Klemens Morgenstern via Boost
>
>
> On 3 Oct 2023, at 09:04, Klemens Morgenstern via Boost <
> bo...@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):
>
> <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>
>
> 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.
>
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.
>
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
>
Peter Dimov via Boost
> That is, the name boost.async would mean C++20 coroutines based.
Christian Mazakas via Boost
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. 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`.
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 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.
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.
- Christian
Glen Fernandes via Boost
> I emphatically support the name ACE or just Ace for this library
>
http://www.dre.vanderbilt.edu/~schmidt/ACE.html
Glen
Vinnie Falco via Boost
bo...@lists.boost.org> wrote:
> I emphatically support the name ACE or just Ace for this library
>
I don't.
Thanks
Klemens Morgenstern via Boost
bo...@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.
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`.
>
>
> 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++.
>
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.
>
>
> 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.
>
The only thing that supports symmetric transfer in asio is the
experimental::coro. Nothing else, so all synchronization utilities must go
through an executor.
Andrzej Krzemienski via Boost
bo...@lists.boost.org> napisał(a):
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;
Vinnie Falco via Boost
bo...@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?
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
Andrzej Krzemienski via Boost
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;
Andrey Semashev via Boost
>
> 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?
ever accepted into the standard but which are generally very much
useful. Boost.Spirit, Boost.Intrusive, Boost.Fusion, Boost.MPL, to name
a few examples. (Yes, MPL has fallen out of favor lately, but one cannot
overestimate its impact before wide adoption of C++11.)
I'm not saying anything about the libraries you mention. I have no
experience with them, nor am I familiar with their domain. I'm just
saying that targeting the standard library has never been the criteria
for accepting libraries into Boost.
Klemens Morgenstern via 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.
> 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".
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.
Klemens Morgenstern via Boost
> 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.
>
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.
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).
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?
brought up should be addressed during review
I would really like a review wizard to clarify what valid grounds for
disputing a review are.
Vinnie Falco via Boost
klemensdavi...@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
> I also find the question "does it belong in boost" misguided. If it passed
> review, it belongs in boost.
That is probably true and helpful for most reviews but we are talking about
outliers. I was never given any instructions on what belongs in Boost.
There is no place anyone can go to answer this question for themselves. For
example, does a library with no users, no field experience, whose API is
not based on any other model, for which the intention is to "shove it in
Boost and see who uses it" qualify as "belonging in Boost?" I wish we knew.
The simple formula of "if it passed review, it belongs in boost" is
unfortunately not a healthy or sustainable model.
Libraries akin to async have been around in other languages for a very long
> time.... How big does the user-base need to be and how would this be
> measured
>
On this, we agree. That there is a need for *something* along the lines of
Boost.Klemens.Async, is not disputed. In fact, one could say that the
demand is so high, that Not-In-Boost.Klemens.Async should gain traction on
its own even without the need to be included in the distribution.
> 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.
>
Again I find myself in agreement here. The review process most of the time
"just works" but every so often we get just the right combination of review
manager, author, library, and "direct to Boost" philosophy on a
controversial tech that answering the question of "does this belong in
Boost" suddenly is not simple. And we end up with reviews that proclaim
acceptance if for no other reason than "coroutines are important and Boost
has to _do something_ about them" without any practical experience. I want
to stress that I am not saying every library needs field experience. This
is different from WG21 - where I believe that ANY proposed library-only
solution should bake for years. For Boost we do not need such a high bar.
But a controversial library from a particular author with a particular
review manager in a particular subject for which there is little to no
field experience, I think that it needs to prove itself.
If it was me proposing Boost.Async, and someone said "hey Vinnie you need
to get some users" I would simply withdraw my library from consideration
and spend the next year getting those users. That you are arguing with me
and not putting in the work to market your library and work with other
projects to get them to use it, is a red flag. I would make sure that when
my library goes up for review there is a cadre of existing users standing
with me and making their presence felt virtually ("accept this library or
we will become loud!"). Boost.Klemens.Async has no cadre of existing users.
No other project uses it. Basically this library is like an unhoused person
asking for handouts "please accept my library even though I have no users."
As a matter of pride I would never allow my hard work to limp into a review
with no support.
Thanks
Vinnie Falco via Boost
> On Sun, Oct 8, 2023 at 1:26 PM Klemens Morgenstern <
> klemensdavi...@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.
Espen Harlinn via Boost
>> This perfectly describes the library and is a nice short name that's unique and pops.
ACE used to be *the* library for much of what asio now provides ...
- Espen
Peter Dimov via Boost
> 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.
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.
Emil Dotchevski via Boost
wrote:
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.
Vinnie Falco 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.
Thanks
Emil Dotchevski via Boost
wrote:
>
> On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost <
bo...@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. :)
Vinnie Falco via Boost
bo...@lists.boost.org> wrote:
> I don't see anything wrong with an author seeking acceptance in Boost as a
> way to acquire users.
>
Then let me educate you. Users correctly or incorrectly presume that all
libraries in the Boost collection will have the same consistently high
level of quality in terms of library API, documentation, performance, and
fitness to task. As this is almost impossible to sustain over time,
eventually an experienced Boost user recognizes that some libraries are
better than others. And they may discover that some libraries are a trap,
unable to deliver on their promises, or perhaps they are not as well
maintained anymore. In other words quality varies significantly from
library to library. During the "golden age of Boost" which occurred at the
inception of Boost and stretched until 2011, this was less of a problem as
the people proposing libraries were experts in the field who also
participated in the standards process. But now there is less participation
in Boost and more participation in the standardization process. Mailing
list volume is down and fewer reviewers appear for new libraries. Boost
also lost its Great Founders and momentum slowed.
I was told a long time ago that the formal review process is as much about
evaluating the author as it is about evaluating the library. Because once a
library goes into the collection it needs to be maintained, and only the
original author has the best understanding of the library and how it might
evolve over time. For example an author of inconsistent temperament who
might abandon their library after it passes a review would be harmful to
the integrity of the collection. I'm not saying this is applicable in this
case but we have a similar problem.
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.
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?
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?"
Sad.
Thanks
Klemens Morgenstern via Boost
<bo...@lists.boost.org> wrote:
>
> On Sun, Oct 8, 2023 at 4:41 PM Peter Dimov via Boost <bo...@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.
>
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.
Vinnie Falco via Boost
klemensdavi...@gmail.com> 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?
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?
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.
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.
Thanks
Klemens Morgenstern via Boost
> 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.
> 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?
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?"
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.
Vinnie Falco via Boost
klemensdavi...@gmail.com> wrote:
> 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.
>
That is all wonderful but I think it should go into the documentation, not
the list.
Thanks
Vinnie Falco via Boost
klemensdavi...@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
Klemens Morgenstern via Boost
>
> On Sun, Oct 8, 2023 at 6:27 PM Klemens Morgenstern <klemensdavi...@gmail.com> 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.
Christian Mazakas via Boost
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.
- Christian
Vinnie Falco via Boost
bo...@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
oliver.kowalke--- via Boost
>library and should come back when its >place in the ecosystem has solidified.
Hans Dembinski via Boost
> On 9. Oct 2023, at 09:27, oliver.kowalke--- via Boost <bo...@lists.boost.org> 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.
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.
John Maddock via Boost
+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...
John.
Niall Douglas via Boost
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
Vinnie Falco via Boost
bo...@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?
Regards
Niall Douglas via Boost
> On Mon, Oct 9, 2023 at 9:57 AM Niall Douglas via Boost
> <bo...@lists.boost.org <mailto:bo...@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
Vinnie Falco via Boost
bo...@lists.boost.org> wrote:
> 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.
>
We have a repository for the new website docs:
https://github.com/cppalliance/site-docs
And we have a dedicated Staff Writer, Peter Turcan, who maintains this. So
if one or more members of the community would like to start this review
process doc, even if it is just copying and pasting select quotes from the
mailing list (like some of the things in your previous message), it is a
start, and Peter can work on filling that out (he might be asking questions
if necessary).
The logical place to put this information would be in the "Boost Formal
Reviews" documentation which is located here in the new website:
https://www.preview.boost.org/doc/formal-reviews/index.html
The Antora source (which holds the table of contents and individual
asciidoc pages) is here:
https://github.com/cppalliance/site-docs/tree/develop/formal-reviews/modules/ROOT
The #boost-docs channel in the Official C++ Slack Workspace (
https://cpplang.slack.com, email me for an invite) is where Peter toils and
responds to the community if you want to drop in and have a chat.
Thanks
Vinnie
Andrzej Krzemienski via Boost
klemensdavi...@gmail.com> napisał(a):
> >>
> >> 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?
>
As indicated in my original review, I have small experience with
asynchronous computations, so to some extent I have to rely on things like
intuition or trust in other experts' opinions. Vinnie's description "C++
needs coroutine libraries, this is a coroutine library, so let's have it"
correctly addresses my attitude. This is not a criticism of your library,
rather of my attitude. I am not particularly proud of it, but I must admit
this is the case. And this clouded my judgement. Now that other peoples'
critical opinions cooled my enthusiasm, I realise that the concerns I
raised as conditions for acceptance are more serious.
I believe a Boost.Library should have a solid design that is reflected in
its documentation. That is, not only should it be solid, but you also
should demonstrate it (in the docs). I am missing this from reading the
docs. The choice of names (promise, task), the concepts that I cannot grasp
after hours of struggling (spawning, interrupting, detaching), the parts of
the design of generator that you admit may make no sense (eager value
consuming generator), this all is a signal for me that the library might
not have a solid design. I may be wrong about this, of course, but I would
rather err on the safe side, and hence my decision. I understand the
recommendation to reject as saying, "do not accept the library in its
current shape, give the author the time, guidance and opportunity to come
back with the improved design." I now think that unclear design is too
serious for conditional acceptance.
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 understand that an async library needs a scheduler. The docs say, "async
uses an asio::io_context as its default event loop" which implies that it
can be used with other event loops. You give two examples
> 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.
>
I must admit they are too complicated for me. But let me ask a question
instead. If I am using my own event loop in my project, how do I adapt it,
so that it is usable with Boost.Async? I do not expect an explanation in
this distribution list. I would expect an answer in the docs.
I am not that much concerned about the user base, or novelty, or the number
of reviews. But it is this lack of certainty that the design is solid and
stable. My apologies for not indicating it earlier. I guess I feel
uncomfortable recommending a rejection after the author spent so much time
developing the library, fine tuning it and answering all my questions.
I hope that this reply makes sense.
Regards,
&rzej;
Robert Ramey via Boost
> On Sun, Oct 8, 2023 at 5:31 PM Emil Dotchevski via Boost <
> bo...@lists.boost.org> wrote:
>
>> I don't see anything wrong with an author seeking acceptance in Boost as a
>> way to acquire users.
>>
>
> Then let me educate you.
LOL
> 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.
I would note that many libraries have been accepted into Boost with zero
users. In fact many libraries have been accepted into Boost that have
many weaknesses and problems with the condition that these be addressed
before the library is released.
This is certainly the case with the two libraries I'm responsable for:
Serialization an Safe Numerics. When I proposed serialization the first
time it was rejected for a lot of good reasons. Nothing wrong with
that. The review was very helpful to me and motivated me to double down
and address all the noted short comings. It was accepted a year later.
When I proposed Safe Numerics, it had a lot of problems and design flaws
and relative little interest from users. (not that it has a lot today).
But enough reviewers thought that it had potential to be useful if it's
issues were addressed. I don't know that these experiences are typical.
But it seems to me that very few Boost libraries have significant
users before being proposed for inclusion in boost.
> 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?"
I don't think it's sad at all. Seems to me like its the traditional way
of doing things. One needs the Boost imprimatur to get any users at all.
Robert Ramey
Richard Hodges via Boost
Sent from my iPad
> On 9 Oct 2023, at 06:21, Christian Mazakas via Boost <bo...@lists.boost.org> 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 Mazakas via Boost
Sure, I'll admit I was wrong.
I just remember seeing a user on slack try out Async during the first
review period and it immediately segfaulted during a client SSL
handshake so I assumed there was no one using this library in
production.
Or rather, no users with a vested financial stake were using it in an
environment where it mattered.
As a runtime author, you basically can't write enough tests for this
kind of code.
I would've advised running Async's `use_op` over an existing Asio
codebase/app before being accepted but eh.