"C++" and "Coroutines". Who would have thought.
But, considering the accelerated releases post C++ 11, I guess I'm not surprised.
The Downsides of C++ Coroutines
11–20 of 51 posts
Re: The Downsides of C++ Coroutines
#12This article hits on a number of interesting points. There is a lot of complexity to be aware of when using C++ coroutines. And a number of “normal” practices become dangerous in them, such as pass by reference. That said, I think they are still very much worth it. Older asynchronous programming libraries in C++ are so verbose and so much worse than coroutines that it’s an obvious choice to use coroutines. Also, ther…
>RAII lock wrappers
You don't even need coroutines for this to be dangerous. Holding locks over callback invocations is a pet peeve of mine in PR reviews. Callback invocations, like suspension points, can inject arbitrary operations into our code, which can easily break prior invariants, yet look innocuous for the casual reader.
Re: The Downsides of C++ Coroutines
#13There is nothing inherently asynchronous about coroutines. You can use them to model concurrency or even parallelism, but that's only a subset of their use cases.
What are some of the other use cases?
Re: The Downsides of C++ Coroutines
#14This article hits on a number of interesting points. There is a lot of complexity to be aware of when using C++ coroutines. And a number of “normal” practices become dangerous in them, such as pass by reference. That said, I think they are still very much worth it. Older asynchronous programming libraries in C++ are so verbose and so much worse than coroutines that it’s an obvious choice to use coroutines. Also, ther…
I don't understand how it is any more verbose.
Because you have to keep explicitly passing state between each callback, rather than just using the same context (which still has the ability to delete things if needed).
Re: The Downsides of C++ Coroutines
#15Besides that they are yet another feature in the bloated hash mess that is c++?
Re: The Downsides of C++ Coroutines
#16This article hits on a number of interesting points. There is a lot of complexity to be aware of when using C++ coroutines. And a number of “normal” practices become dangerous in them, such as pass by reference. That said, I think they are still very much worth it. Older asynchronous programming libraries in C++ are so verbose and so much worse than coroutines that it’s an obvious choice to use coroutines. Also, ther…
As someone who writes in C++ and uses coroutines everyday for work, I find for our use case this is actually helpful.
We use seastar.io a thread per core framework and locks are "async" friendly in that they yield for access instead of blocking. Also embracing fully async message passing between threads simplifies the programming model a ton.
Re: The Downsides of C++ Coroutines
#17I do not understand yet (open to explanations!) what is the difference between stackless and stackful coroutines in the fact that stackless should be cheap and even "collapsable" when nested in lifetimes but if it is not the case... stackful is cheaper.
Are not stackless supposed to be more performant? In which cases? Yes I know their virality, potential heap allocations, etc.
Re: The Downsides of C++ Coroutines
#18Re: The Downsides of C++ Coroutines
#19There is nothing inherently asynchronous about coroutines. You can use them to model concurrency or even parallelism, but that's only a subset of their use cases.
What are some of the other use cases?
Many coroutine uses are not asynchronous, but synchronous, they block when resumed and do not execute in parallel. This permits cooperative multitasking, versus preemptive (or preemptive with a bunch of locks to imitate cooperative which is, of course, a waste). Since they can, in principle, execute within the same thread (with C++'s implementation and some others you the programmer can send them off to other threads for execution, but that's an explicit choice) this can simplify concurrent system design and execution (in the concurrency is not parallelism sense). In the single threaded case, it's also faster than multithreaded asynchronous code since the context switching (modulo cache misses) is greatly reduced. Especially useful in the case where you want synchrony and not asynchrony.
They're also very useful if you've ever had to create a bare metal multitasking system. Much easier for state management than older style "while (true)" loops with a million state variables so functions can resume via a switch/case as pseudo-coroutines. (Well, easier if you don't have to implement the coroutine mechanism yourself.)
Re: The Downsides of C++ Coroutines
#20Experience teaches me that the worst time to use a new design pattern or technique is _right after you learn about it_. The problem in your code base you thought about while learning the pattern was a useful proxy for where it could be applied, but that doesn't mean it's the right fit. Do it in a scratch refactoring, and wait a week or two before you consider merging it. And make sure you are emotionally as ready to…
I agree that you should always be ready and happy to discard or refactor code as needed. Requirements change, your assumptions may be wrong.
But in practice I've more often seen the opposite problem, where organizations end up stuck on C++11 for a decade for no technical reason. It's good to explore the new stuff and eventually adopt what you can use.