Great talk with some deep knowledge sharing, and makes me more hopeful for broader use of co-routines! (Jacobs sure seems to be :) ) Making `Co` non-moveable and having a separate Future that takes values seems to be a great way to solve the parameter lifetime issue. The event wait/notify appraoch (delaying the work-stealing to the next suspend) and the cancellation approach (like an exception was thrown when co_await-ing) keeps things neat. Also, he constant theme of stack frame elision is brilliant Overall, a bunch of ideas that it seems every coro library should take note of! Also, several examples of weird concurrency that comes up when having lots of users...
"You can't count on any sort of expertise". Hearing this makes me crazy. Companies are spending so much to make every employee a replacable cog. Even Google.
I implemented my own fibers from scratch some time ago. instantly had some bizarre issues that turned out to be stack overflows. in my code I sent all my fibers to a function that simply printf:ed the ID of the thread and apparently 4kb of stack per fiber was not enough to handle that.
Interesting ideas but not a fan of the closed api. This is all to support his cancelation and the cost is it not working with thirdparty awaitables. Well maybe he has an await_transform in there? Idk, but I think coroutines coolest part is the open api.
Thr pervasive use of C++ at Goolge is why so many postmortems have been written by SRE over the years. Throw it in the tashcan where it belongs and use modern safe languages like Go and Rust for your backend micrroservices.
Great talk with some deep knowledge sharing, and makes me more hopeful for broader use of co-routines! (Jacobs sure seems to be :) ) Making `Co` non-moveable and having a separate Future that takes values seems to be a great way to solve the parameter lifetime issue.
The event wait/notify appraoch (delaying the work-stealing to the next suspend) and the cancellation approach (like an exception was thrown when co_await-ing) keeps things neat. Also, he constant theme of stack frame elision is brilliant
Overall, a bunch of ideas that it seems every coro library should take note of!
Also, several examples of weird concurrency that comes up when having lots of users...
Coroutines and job systems complement each other beautifully.
Great talk!
I like the idea of splitting Co and Future.
44:30 ok can he tell us the magic implementation details?
"You can't count on any sort of expertise". Hearing this makes me crazy. Companies are spending so much to make every employee a replacable cog. Even Google.
Is this library open source or planned to be?
I implemented my own fibers from scratch some time ago. instantly had some bizarre issues that turned out to be stack overflows. in my code I sent all my fibers to a function that simply printf:ed the ID of the thread and apparently 4kb of stack per fiber was not enough to handle that.
Interesting ideas but not a fan of the closed api. This is all to support his cancelation and the cost is it not working with thirdparty awaitables. Well maybe he has an await_transform in there? Idk, but I think coroutines coolest part is the open api.
Senders/Receivers is apparently preferring structured concurrency.
>50% ? ? ?
Nice talk, but I got a feeling this was partially inspired by ASIO, would be nice if presenter or somebody from audience addressed that point.
Thr pervasive use of C++ at Goolge is why so many postmortems have been written by SRE over the years. Throw it in the tashcan where it belongs and use modern safe languages like Go and Rust for your backend micrroservices.