I am pretty okay with the code (I'm essentially talking about the usage syntax for the library and its type) shown in the examples. However, at this point any parallel computing implementations must address the baseline issues presented in "Scalability! But at what COST? (McSherry,Isard,Murray 2015)" a paper whose central question is can a parallel computation exhibit a Configuration that Outperforms a Single Thread (the COST in the title). [1] There is a good discussion of the paper and its applicability to parallel (and distributed) computation implementations in Richard Feldman's 2024 Distributed Systems talk "Distributed Pure Functions". [2]

At this point in the life-cycle of the concept of parallel computation, I think it has become somewhat imperative that devs in the area begin to honestly evaluate the practicality and benefits/drawbacks of using the techniques for a given application area and attempt to 'sell' their libraries, techniques, idioms, etc using a more transparent approach. Also, I generally think that people that argue for more prevalence of parallel code, especially those arguing for the default being parallel (or concurrent), have to wrestle with and address these same issues.

Again, I don't dislike the premise of the library, think the usage examples seem very sensible and well designed, and I really like parallel computation as an area of study in general. Further, I really think that setting out a task for one's self

'to try building a library using modern features from the C++ standard library. I’ve used coroutines for task encapsulation and C++23 expected for exception handling, while trying to maintain good performance.'

after taking inspiration from two well respected and frequently utilized libraries in the space is great and the internals of the library I saw look clean and well architected.

1 - https://www.usenix.org/system/files/conference/hotos15/hotos... 2 - https://youtu.be/ztY1YRiaSiE?si=npBREw9vdF5dHcJh&t=350

There's also a high-quality, sophisticated Threading Building Blocks by Intel (which I wish would become a part of the C++ standard library).

https://en.wikipedia.org/wiki/Threading_Building_Blocks

At Meta folly::Coro is used pretty heavily. Have you taken a look at it? Wondering if there are any advantages. The api seems fairly similar to me at a glance.

https://github.com/facebook/folly/tree/main/folly/experiment...

It would be great to have examples with I/O and timers/sleeps, since this is what people will likely use the library for. Also, communication between tasks.

I tried getting into C++ coroutines in the past and I was put off because of the complexity and the lack of an I/O system that was understandable by a human being.

It would be nice if there was a function to wait for tasks and to return the results at the same time, so that you could write something like:

    auto [a, b] = co_await coros::wait_tasks(fib(n - 1), fib(n - 2));
    return a + b;

I just can't get my brain around coroutines.

Can anyone recommend a good tutorial or resource for me to read.

I find it so frustrating as I don't think it's necessarily a complex subject but my brain just doesn't get it.

Related perhaps but many (many, many) years ago, when learning BASIC, I assumed GOSUB went off and started executing the code in the subroutine as well as the rest of the inline code. That suggests to me that I should perhaps have a deeper understanding of this but I really don't...

Looks like a good start. I'm not actually sure I'd use it on windows however. CPPWinrt has a really decent coroutine support library with tools like winrt::resume_background() [1], I use it extensively even in desktop apps because it makes using the windows threadpool (which is active by default for all windows processes since at least windows 7) trivial. I've basically moved most of my threading code onto that unless I need a dedicated thread to hold a context for some reason. But, that's a windows specific thing as far as I know.

[1] https://learn.microsoft.com/en-us/uwp/cpp-ref-for-winrt/resu...

Have you compared perf with the reference implementation of the P2300 “Senders” proposal? https://github.com/NVIDIA/stdexec

Is there a way to prevent callback hell in C++ when doing asynchronous communication with C++ before 20? Coroutines seem to be the only clean solution. Promises can work, but they tend to be difficult to reason about if branching is involved.

Martin, interesting; have you had a look at https://github.com/taskflow/taskflow ?

In your dequeue/circular buffer implementation, how is it able to grow the queue without locking?

The code seems to rely on atomics for head & tail, but grows the queue without any special provisions I can see.

https://github.com/mtmucha/coros/blob/ee30d3c1d0602c3071aa26...

This looks very promising, it's refreshing to see a library with a sane interface.

One thing I'd like to see is the possibility to run the coroutines in the main thread, without spawning any new threads in the thread pool. It might seem strange but sometimes you just need to do I/O stuff concurrently in a place where you're not allowed to spawn other threads.

Other than that congrats on the release, I hope you keep working on it!

A great project.

FYI: I guess there is a minor typo in the README example: the argument of the second call to fib() in the non-coros version of the code should be "n-2" and not "n-1".

This looks exactly like .NET's task abstraction.

If it works anywhere near as good, I'm definitely giving this a try next time I need to work on a C++ project. Thanks!

Have you had a look at SeaStar and how it works with coroutines?

How is this library different from Boost.Cobalt and cppcoro?