[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)