4 ms·

Short version: The coroutines are regular threads. The library provides an interface for syncing which makes them behave as if they were "real" coroutines. Thi

Short version: The coroutines are regular threads. The library provides an interface for syncing which makes them behave as if they were "real" coroutines. This avoids common problems you run into when making coroutines in C++ which by itself does not support coroutines natively - but it supports threads very well. Pros: Very easy to implement and use. Will likely work very well anywhere without much thought. Cons: Resource hungry. Not really designed for thousands of simultaneous coroutines.

vvanders 11y ago
Yeah, we'd traditionally use coroutines per-actor so this would be way too heavyweight. It's really nice for scripting things as you can tests a bunch of conditions, yield() and then re-test without needing to build an explicit state machine. Much easier for designers to grok. Usually done in Lua, which is a fantastic language for gamedev(low overhead, fast, coroutine support and integrates very nicely with C/C++).
jasonjei 11y ago
Question: couldn't you use OS fibers to do "coroutines" without being resource intensive? I know all major OS kernels have supported fibers for some time...
- gpderetta 11y ago
  Linux for one doesn't unless you count the obsolete (and slow) swapcontext.
  - acconsta 11y ago
    Google implemented fibers. Hopefully they'll get upstreamed. https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw
    - gpderetta 11y ago
      If I remember correctly, that's an additional interface for usermode initiated, cooperative scheduling of kernel threads (basically a variant of pthread_yield that allows specifying which thread is going to get the timeslice we are relinquishing). It still requites a syscall and the entities being scheduled are proper kernel level threads. So not really fibers. Pretty cool though. Edit: autocorrect
- rumcajz 11y ago
  You can use this: http://libmill.org http://libmill.org
thechao 11y ago
I've recently just started using pthreads with blocking pipes. Not performant, but dead easy to use & reason about.
- slavik81 11y ago
  Whoops. I think I downvoted you by mistake. By the way, I found barriers to be very simple to work with for some rough multithreading. Just line all the threads up, then let them go.

vvanders 11y ago

Yeah, we'd traditionally use coroutines per-actor so this would be way too heavyweight. It's really nice for scripting things as you can tests a bunch of conditions, yield() and then re-test without needing to build an explicit state machine. Much easier for designers to grok. Usually done in Lua, which is a fantastic language for gamedev(low overhead, fast, coroutine support and integrates very nicely with C/C++).

jasonjei 11y ago

Question: couldn't you use OS fibers to do "coroutines" without being resource intensive? I know all major OS kernels have supported fibers for some time...

gpderetta 11y ago
Linux for one doesn't unless you count the obsolete (and slow) swapcontext.
- acconsta 11y ago
  Google implemented fibers. Hopefully they'll get upstreamed. https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw
  - gpderetta 11y ago
    If I remember correctly, that's an additional interface for usermode initiated, cooperative scheduling of kernel threads (basically a variant of pthread_yield that allows specifying which thread is going to get the timeslice we are relinquishing). It still requites a syscall and the entities being scheduled are proper kernel level threads. So not really fibers. Pretty cool though. Edit: autocorrect
rumcajz 11y ago
You can use this: http://libmill.org http://libmill.org

thechao 11y ago

I've recently just started using pthreads with blocking pipes. Not performant, but dead easy to use & reason about.

slavik81 11y ago
Whoops. I think I downvoted you by mistake. By the way, I found barriers to be very simple to work with for some rough multithreading. Just line all the threads up, then let them go.