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