[HN Gopher] C++20: Building a Thread-Pool with Coroutines ___________________________________________________________________ C++20: Building a Thread-Pool with Coroutines Author : MichaEiler Score : 36 points Date : 2021-05-21 13:58 UTC (1 days ago) (HTM) web link (blog.eiler.eu) (TXT) w3m dump (blog.eiler.eu) | tele_ski wrote: | Really nice write up! I'm excited to see more coroutine tutorials | and guides come out, I think this C++20 feature has huge | potential to make C++ easier to use over the next decade. I will | also say I was a bit surprised to see libcoro linked in the | article! I'm glad you found it useful but I need to give most of | the credit to Lewis Baker's cppcoro as well -- I learned most of | what I implemented into libcoro from his fantastic repository and | then tuning the coroutine primitives to how I'd want to use the | library for an HTTP web server. I just generally find there is no | better way to truly learn a difficult concept than to roll your | own version. | secondcoming wrote: | I'll admit I find coroutines difficult to grok. It seems to me | that 'callback hell' is turning into 'coroutine hell'. The only | plausible use-case I can see is enabling functionality similar to | that of Python's `yield`. | | Does threadpool::thread_loop() not have to check if the popped | coroutine is suspended before attempting to resume it? | | Are they really more efficient than normal callbacks when doing | async? | drenvuk wrote: | 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 want to batch a bunch of database operations | into one transaction. You could queue them up over the course | of a few milliseconds, run the transaction, and then for each | context that relied on different db operations simply return to | each's previous point instead of having to call a handler. | Granted, the handler is now inside of the `await_transform` | needed to work with `co_await` but think of the possibilities. | No weirdly separate callback function, no real need to make a | class that encapsulates all of the operations for let's say a | user's post request, and to top it all off, you can do this on | a single thread. It's a tool for cleaner code but I'll be | damned if it is really easy to understand. | | It's just so much stupid boiler plate and a strange way of | putting it together. ___________________________________________________________________ (page generated 2021-05-22 23:00 UTC)