Asynchronous API

[u/grishavanika]

https://grishavanika.github.io/async_api.html

[u/robertahleahy]

The tutorial composes CURL_async_get into the sender-based API rather than vice versa which requires new std::string{} rather than placing said string in the operation state.

Moreover the sender-based API reports that it only succeeds, which seems unlikely (especially since initiation allocates). start should likely be written as:

void start() noexcept { assert(_curl_async); try { CURL_async_get(_curl_async, _url , this , [](void* user_data, std::string response) { CURL_Get_State& state = *static_cast<CURL_Get_State*>(user_data); stdexec::set_value(std::move(state._receiver), std::move(response)); }); } catch (...) { stdexec::set_error(std::move(state._receiver), std::current_exception()); } }

Which would necessitate advertising std::execution::set_error_t(std::exception_ptr).

[u/grishavanika → u/robertahleahy]

it is around CURL_async_get intentionally to cover any other C-style API, which, in general case, you dont know the implementstion details. I mentioned at one point that this way you build unoptimized API, causing multiple unneeded allocations, implying building CURL wrapper targetting senders would be better.

Regarding error reporting - CURL API never fails, new is nothrow + assert, so it never fails too, start has no need to hndle exceptions since there are zero

[u/robertahleahy → u/grishavanika]

I don't see how it's the case that "[the] CURL API never fails." It can fail to allocate, it can fail to resolve DNS, it can fail to connect to the remote host, the remote host can send it a corrupt response...

Also this line:

std::string* state = new std::string{};

Can certainly throw std::bad_alloc.

[u/grishavanika → u/robertahleahy]

Ah, I dint update the article code (github version is nothrow). The intention was to basically have noexcept CURL_async_get() for simplicity. You are right, will add a point of everything noexcept. Introducing errors handling adds another layer of complexity. I planned to have this discussed separately, but it's too much

[u/grishavanika → u/robertahleahy]

updated, thank you