Re: [Async] Naming land grab?

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-03 04:34:37

On Tue, Oct 3, 2023 at 5:06 AM Alan de Freitas via Boost
<boost_at_[hidden]> 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.
>