Open lewissbaker opened 7 years ago
Why would when_all
return a task
?
You're right it doesn't have to return a task
.
It could return a when_all_awaitable
type that holds on to the input operations and the nested coroutines. This would avoid the allocation of one coroutine frame as you could just reuse the coroutine frame of the awaiter of when_all_awaitable
to act as the continuation.
This could also allow RVO of the returned tuple as the consuming coroutine would be the one to call await_resume()
and so we wouldn't need to stash a temporary value inside the task
promise.
Good idea, @ericniebler :)
Good idea, @ericniebler :)
LOL!
Commit 86a429aead1367550b5fbbf70e5827386e972548 adds a generic implementation for variadic when_all
.
I'm still not sure what should be done about result-type of generic co_await when_all(someSequenceOfAwaitables)
.
Should it yield a vector<awaitable_result_t<awaitable>>
?
This has now largely been implemented as of c2576ad2980959d938a98924fcd68139dc4bf4af.
I'm still working on updating the documentation to reflect the changes to when_all()
as well as to other operations like fmap()
, schedule_on()
, make_task()
, etc.
Once this has been done then I'll merge the 'generic_ops' branch back into 'master'.
For example, allow passing a
cppcoro::file_read_operation
into the variadicwhen_all
overload.Also see if we can get rid of the need for intrusive
get_starter()
methods ontask
andshared_task
and instead just create N temporary coroutines withinwhen_all
to use as the continuation for each of the awaitable operations.If possible, I'd still like to retain the behaviour such that if
when_all
successfully returns atask
without throwingstd::bad_alloc
that then you can guarantee thatco_await
ing the returned task will start each of the async operations and wait until they all complete.