[HN Gopher] C++ coroutines: Understanding the compiler transform
       ___________________________________________________________________
        
       C++ coroutines: Understanding the compiler transform
        
       Author : ibobev
       Score  : 36 points
       Date   : 2022-08-29 20:01 UTC (2 hours ago)
        
 (HTM) web link (lewissbaker.github.io)
 (TXT) w3m dump (lewissbaker.github.io)
        
       | synergy20 wrote:
       | these days you have std::async(promise+future via channel),
       | std::thread(e.g. pthread style) and coroutines in modern C++. my
       | understanding is std::async is a simpler API for parallel coding,
       | thread for finer grained control, while coroutine is running on
       | one core|cpu by design thus it needs to work with threadpool(i.e.
       | using std::thread) or something else to utilize all cores, unlike
       | std::async or std::thread, both are multi-core ready.
        
         | interroboink wrote:
         | Don't forget the upcoming "executors" concept. Good talk w/Eric
         | Niebler on why promise/future is not so great[1] and
         | P0443R14[2]. Seems like it won't make it for C++23, though.
         | [1] https://www.youtube.com/watch?v=tF-Nz4aRWAM&t=778s
         | [2] https://www.open-
         | std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r14.html
        
           | synergy20 wrote:
           | Good to know. std::async for simple and less intensive cases,
           | for anything serious std::thread might be the way to go,
           | before executors is real that is.
        
           | inetknght wrote:
           | > _Seems like it won 't make it for C++23, though._
           | 
           | Why is that?
        
             | interroboink wrote:
             | I'm not involved, but it seems like they haven't managed to
             | get it fully baked in time for the cutoff. Some more
             | discussion at: https://old.reddit.com/r/cpp/comments/sshm7n
             | /did_unified_exe...
        
         | jcelerier wrote:
         | Coroutines are a tool for concurrency, threads a tool for
         | parallelism - see e.g.
         | https://stackoverflow.com/questions/1050222/what-is-the-diff...
         | . In my new code coroutines have entirely replaced futures,
         | they make the code much more readable. They can also be used
         | for use cases where parallelism is irrelevant, for instance for
         | generators.
         | 
         | Think of coroutines as a language-level way to turn procedural-
         | looking call trees into state machines where the caller can
         | control when and how the transitions of the state machine
         | happen.
        
           | bronxbomber92 wrote:
           | Threads are also a tool for concurrency.
        
           | synergy20 wrote:
           | concurrency is a bit overused term, in the early stage it was
           | referring to parallelism too, anyways yes I know the
           | difference between pthread vs coroutines.
           | 
           | the problem of coroutine with me is how to use it on multiple
           | core systems, my current thought is to have a pthread-pool in
           | the # of cores, each thread can run multiple coroutines, as
           | again, coroutine seems not an ideal fit to leverage multiple
           | cores. The pthread-pool + coroutine approach is a combination
           | with simpler code and multicore usage to me.
        
           | jjtheblunt wrote:
           | difference between concurrency and parallelism in present
           | lingo is what?
           | 
           | we didn't distinguish in the early days (early 1990s) of
           | working on parallelizing compilers and proliferating shared
           | memory multiproceesors, as i recall, and first heard someone
           | say they meant different things about 12 years ago, so a
           | person roughly 15 years younger than me.
        
             | notacoward wrote:
             | I was also working on early multiprocessors in the early
             | 90s, and it's true that the terms were often treated as
             | synonyms then, but for at least half of the time since then
             | the distinction has been clear and pretty well agreed upon.
             | Concurrency refers to the _entire lifetimes_ of two
             | activities overlapping, and can be achieved via scheduling
             | (preemptive or cooperative) and context switching on a
             | single processor (core nowadays). Parallelism refers to
             | activities running literally at the same instant on
             | separate bits of hardware. It doesn 't make a whole lot of
             | sense etymologically, might even be considered backward in
             | that sense, but it's the present usage.
             | 
             | Note: I deliberately use the generic "activity" to mean any
             | of OS threads, user-level threads, coroutines, callbacks,
             | deferred procedure calls, etc. Same principle/distinction
             | regardless.
        
       | user5678 wrote:
        
       ___________________________________________________________________
       (page generated 2022-08-29 23:00 UTC)