Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++20: Building a Thread-Pool with Coroutines

blog.eiler.eu

Post reply on HN
Print view View original

21–30 of 63 posts

Re: C++20: Building a Thread-Pool with Coroutines

#21

Post by cletus »

ninepoints wrote: post #18
cletus wrote: post #8

C++20 coroutines confuse me. Like it's not clear to me what problem they solve. For the last few years I've been doing Hack (Facebook's PHP fork) professionally and async-await as cooperative multitasking is pervasive. IMHO it's a really nice model. Generally speaking, I've come around to believing that if it ever comes down to you spawning your own thread, you're going to have a Bad Time. Go's channels are another v…

You're missing the big idea a bit. Coroutines in C++ can be used to implement generators or goroutines or async/await, etc. They are intended for library authors as a lower level construct. See for example: https://www.jeremyong.com/cpp/2021/01/04/cpp20-coroutines-a-...

I literally said this at the end of my comment about coroutines being a low-level primitive.

Re: C++20: Building a Thread-Pool with Coroutines

#22

Post by dundarious »

cletus wrote: post #21
ninepoints wrote: post #18

Earlier quoted context omitted.

You're missing the big idea a bit. Coroutines in C++ can be used to implement generators or goroutines or async/await, etc. They are intended for library authors as a lower level construct. See for example: https://www.jeremyong.com/cpp/2021/01/04/cpp20-coroutines-a-...

I literally said this at the end of my comment about coroutines being a low-level primitive.

You raised two hypotheticals and said you honestly don't know if either/both/neither are true.

1. Is it like Python generators?

2. Is it a bad example of design by committee and meant as a set of lower level primitives?

GP responded that 2 is correct (but without the sass on design by committee) and that 2 allows for them to implement such things as 1.

I think they gave their opinion as to what parts of your hypotheticals are true, and that is a valuable contribution, and very much not the same as just repeating parts of your comment ("I literally said this").

Re: C++20: Building a Thread-Pool with Coroutines

#23

Post by Matthias247 »

harikb wrote: post #14
cletus wrote: post #8

C++20 coroutines confuse me. Like it's not clear to me what problem they solve. For the last few years I've been doing Hack (Facebook's PHP fork) professionally and async-await as cooperative multitasking is pervasive. IMHO it's a really nice model. Generally speaking, I've come around to believing that if it ever comes down to you spawning your own thread, you're going to have a Bad Time. Go's channels are another v…

Main problems with async await model is that the callee decides whether something should run sync/async. In goroutines model, caller decides

I don't think so. coroutine awaits are just like normal function calls in Go (since all of Go functions are implicitely suspendable).

I guess you meant the "go" statement? That is more of a coroutine spawn thing, and this would be a separate function in C++ too.

Re: C++20: Building a Thread-Pool with Coroutines

#24

Post by jimsimmons »

harikb wrote: post #16
boardwaalk wrote: post #12

Earlier quoted context omitted.

They solve exactly the problem you describe; I'm not sure what you're missing. What are you thinking you can't do? I have a project where I've put C++ coroutines on top of libuv and I can do essentially anything I could do in JS/C#/Rust async/await with task/co_await/etc with the imperative style you'd expect. You may have looked at them at too low a level. Check out something like cppcoro to see what you can do. I d…

While the starvation behavior of cooperative green-threads isn’t ideal as native threads, the idea is that 1. Properly written code will perform well, whether async/await or Go style. 2. Making async easy makes one use it in more places. In additon having caller decide to run something sync or async also makes it way more useful. In Async/await model that can only work if all methods are declared async - very costly…

Good way to put what’s wrong with Python async and probably by extension C++ too. The sync-async in both direction need to be symmetrical for it to make sense. Right now in Python async can interact with Python sync quite comfortably but the opposite direction is a literal black hole. I have had to read up on how sync can interact with async multiple times but I’m still not sure what is the idiomatic way and it always feels like it’s on knife edge even when I get something working.

Obviously, the caveat is that I’m just stupid and don’t understand Python async well enough. But I have a feeling that this is common experience

Re: C++20: Building a Thread-Pool with Coroutines

#25

Post by harikb »

jimsimmons wrote: post #24
harikb wrote: post #16

Earlier quoted context omitted.

While the starvation behavior of cooperative green-threads isn’t ideal as native threads, the idea is that 1. Properly written code will perform well, whether async/await or Go style. 2. Making async easy makes one use it in more places. In additon having caller decide to run something sync or async also makes it way more useful. In Async/await model that can only work if all methods are declared async - very costly…

Good way to put what’s wrong with Python async and probably by extension C++ too. The sync-async in both direction need to be symmetrical for it to make sense. Right now in Python async can interact with Python sync quite comfortably but the opposite direction is a literal black hole. I have had to read up on how sync can interact with async multiple times but I’m still not sure what is the idiomatic way and it alway…

No, it is not you.

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: C++20: Building a Thread-Pool with Coroutines

#26

Post by j16sdiz »

DSingularity wrote: post #20
asdfasgasdgasdg wrote: post #5

Earlier quoted context omitted.

It still boggles the mind that they made it so hard to use this stuff in terms of boilerplate. Hopefully that will all be abstracted into a library that handles io, networking, multiprocessing and synchronization so most of us can just focus on writing the bits that do stuff. But I will never understand how the std maintainers could not manage to do this when every other language is doing async await support in their…

Most of that boilerplate will be hidden in the libraries which use it. Unless you are a library author I don’t know why you would care about the boilerplate-like elements from the standard— you will only use co_yield and co_await.

C++ compilers are famous for their cryptic error messages. Standard Libraries are the reason.

Re: C++20: Building a Thread-Pool with Coroutines

#29

Post by pjmlp »

asdfasgasdgasdg wrote: post #5
drenvuk wrote: post #4

Earlier quoted context omitted.

You're not the only one. Coroutines are complicated as hell and have too much boiler plate BUT once you handle it for a general enough case you get javascript-esque async await syntax which is very, very nice. Take for instance, this code which relies on libuv for its event loop and co_await to retain its state during its execution: https://gist.github.com/Qix-/09532acd0f6c9a57c09bd9ce31b3023... Lets say that you wan…

It still boggles the mind that they made it so hard to use this stuff in terms of boilerplate. Hopefully that will all be abstracted into a library that handles io, networking, multiprocessing and synchronization so most of us can just focus on writing the bits that do stuff. But I will never understand how the std maintainers could not manage to do this when every other language is doing async await support in their…

On Windows that library is WinRT.

Re: C++20: Building a Thread-Pool with Coroutines

#30

Post by logicchains »

jerf wrote: post #19
sys_64738 wrote: post #7

GO style co-routines and native JSON support would pretty much consign GO to history, IMO.

If things could be "consigned to history" by C++ adding more features, there'd hardly be any other languages left! It has all the features. That's its biggest problem.

Noo, it's missing something basic: struct introspection. Unlike almost every other modern language, it's not possible to write a generic "ToJson" or "ToString" that will work for any struct.
Post reply on HN