Results 73 issues of Lewis Baker

The difficult part of designing when_any() will be how to handle cancellation of the co_await operations of the other tasks. Currently, the `task` and `shared_task` types don't allow the caller...

design

Cppcoro now has an `async_mutex` class which provides for exclusive locks in a critical section. However, some data-structures could benefit from a reader/writer lock that allows multiple concurrent readers or...

Extend I/O support to include support for sockets (at least tcp/ip and udp/ip protocols) using winsock and I/O completion ports on top of `cppcoro::io_service`. Needs async methods for: accept, connect,...

If a coroutine wants to return the value of another task as its result then you currently need to `co_await` the other task first and then `co_return` the result of...

With the `when_all_ready(std::vector)` overloads we need to allocate N coroutine frames, one for each awaitable in the list. As the number of coroutine frames that needs to be allocated is...

Rather than returning a collection (tuple/vector) of the original awaitable objects from `when_all_ready`, we should consider returning a collection of the results encapsulated in some kind of `expected` type. This...

For example, allow passing a `cppcoro::file_read_operation` into the variadic `when_all` overload. Also see if we can get rid of the need for intrusive `get_starter()` methods on `task` and `shared_task` and...

Currently, the `generator` and `async_generator` classes return a mutable reference to the yielded value. This can lead to unexpected consequences: ```c++ generator ints(int end) { for (int i = 0;...

From [comment](https://github.com/lewissbaker/cppcoro/issues/45#issuecomment-327645748) in #45.