3 ms·

Coroutines have the distinct disadvantage of needing a stack, much like threads. So-called 'stackless' coroutines aren't really so different to computed gotos i

by nly 11y ago

Coroutines have the distinct disadvantage of needing a stack, much like threads. So-called 'stackless' coroutines aren't really so different to computed gotos in a state machine

amelius 11y ago
For parsing html, you wouldn't need that large a stack. Further, you could make the stack grow dynamically at a very small cost. Also, I bet that even if stackless coroutines are close to FSMs, they are much easier to program.
- exacube 11y ago
  You need green/user-space threads if you want to use co-routines effectively, because if a coroutine blocks, it would block off the entire OS thread from doing anything else.
exacube 11y ago
What are stackless coroutines? What do they look like?
- acidx 11y ago
  Read Adam Dunkels' paper on Protothreads.
  - exacube 11y ago
    Thanks for your comment. I don't know how to feel about Protothreads. It's just syntatic sugar for using a state-machine to provide continuations. You're also not allowed to carry state over between continuations (although I can see how you can extend it to carry-over some struct of data or something). This greatly diminishes the usefulness of Protothreads.. so it feels more like a fun proof-of-concept. Are there any popular/real-world use cases of Protothreads?
    - acidx 11y ago
      Yeah, that's how you end up doing this: store coroutine state in a struct, with an integer that lets you decide where to jump to when you resume the coroutine. With compiler support that can be pretty efficient (gcc has computed goto, for instance). Things get quite awkward in C but similar techniques are manageable in C++. I've never used Protothreads before, but Contiki (the tiny operating system written by the same person) uses them for its process implementation. Similar technique is also used by Putty as well: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
halayli 11y ago
stackless are regular coroutines except that there's 1 stack in the scheduler and when a coroutine yields, the current stack state is saved into the coroutine's structure to be restored later. The disadvantage is that you'll need to copy out/in every time a coroutine yields. It's unrelated to gotos in a state machine. Having a stack per coroutine is not a big deal, especially if the coroutine library regularly advises the kernel on the memory areas it isn't using (madvise). What's stored on the stack usually needs to be stored somewhere else and ends up using a similar account of memory. When you allocate a 1MB stack per coroutine, the kernel will not wire it all to ram, but only the pages that have been touched. When the stack shrinks back and the coroutine yields, the scheduler can call madvise and inform the kernel that the no longer used pages from the 1MB can be reclaimed.

by nly 11y ago

Coroutines have the distinct disadvantage of needing a stack, much like threads. So-called 'stackless' coroutines aren't really so different to computed gotos in a state machine

amelius 11y ago

For parsing html, you wouldn't need that large a stack. Further, you could make the stack grow dynamically at a very small cost. Also, I bet that even if stackless coroutines are close to FSMs, they are much easier to program.

exacube 11y ago
You need green/user-space threads if you want to use co-routines effectively, because if a coroutine blocks, it would block off the entire OS thread from doing anything else.

exacube 11y ago

What are stackless coroutines? What do they look like?

acidx 11y ago
Read Adam Dunkels' paper on Protothreads.
- exacube 11y ago
  Thanks for your comment. I don't know how to feel about Protothreads. It's just syntatic sugar for using a state-machine to provide continuations. You're also not allowed to carry state over between continuations (although I can see how you can extend it to carry-over some struct of data or something). This greatly diminishes the usefulness of Protothreads.. so it feels more like a fun proof-of-concept. Are there any popular/real-world use cases of Protothreads?
  - acidx 11y ago
    Yeah, that's how you end up doing this: store coroutine state in a struct, with an integer that lets you decide where to jump to when you resume the coroutine. With compiler support that can be pretty efficient (gcc has computed goto, for instance). Things get quite awkward in C but similar techniques are manageable in C++. I've never used Protothreads before, but Contiki (the tiny operating system written by the same person) uses them for its process implementation. Similar technique is also used by Putty as well: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

halayli 11y ago

stackless are regular coroutines except that there's 1 stack in the scheduler and when a coroutine yields, the current stack state is saved into the coroutine's structure to be restored later. The disadvantage is that you'll need to copy out/in every time a coroutine yields. It's unrelated to gotos in a state machine. Having a stack per coroutine is not a big deal, especially if the coroutine library regularly advises the kernel on the memory areas it isn't using (madvise). What's stored on the stack usually needs to be stored somewhere else and ends up using a similar account of memory. When you allocate a 1MB stack per coroutine, the kernel will not wire it all to ram, but only the pages that have been touched. When the stack shrinks back and the coroutine yields, the scheduler can call madvise and inform the kernel that the no longer used pages from the 1MB can be reclaimed.