3 ms·

Here's a good (introductory) resource on implementing green threads: http://c9x.me/art/gthreads/intro.html http://c9x.me/art/gthreads/intro.html. It's helpful f

Here's a good (introductory) resource on implementing green threads: http://c9x.me/art/gthreads/intro.html http://c9x.me/art/gthreads/intro.html. It's helpful for learning how they work in practice. Are people running into performance issues with green threads in practice? It seems like they're already pretty performant, particularly if you're using them more as an abstraction for concurrency than as a way to get parallelism. There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. If you really care about performance you probably shouldn't be using green threads at all but should instead be running separate processes on dedicated cores. Green threads also have the advantage over kernel threads in that they don't require the overhead of a kernel context switch, since the context switch can be done in userspace, which requires saving much less context and also affects your caches less.

auxym 11y ago
Why processes vs os-level threads?
- learc83 11y ago
  The OP said processes on dedicated cores, so I guess they meant you should use processes if you need fewer threads than you have available cores. If that is the case then processes could be faster than OS threads because you'd avoid context switches altogether. However, if your system supports pinning OS threads to processors and you limit the number of threads to the number of available processors, I can't think why that wouldn't be just as good.
zzzcpan 11y ago
> There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. Name at least one that cannot be solved better without them.
- rumcajz 11y ago
  Network stacks. And pipelines in general.
  - zzzcpan 11y ago
    Be specific. Network stacks and pipelines are easier even with the most basic event loop, because you simply don't have to think about concurrent memory access whatsoever. But you do with green threads and coroutines.
    - strmpnk 11y ago
      A lot of the edge cases like back pressure and certain kinds of state machines are a lot easier to represent as function calls rather than an asynchronous events. Most of the good implementations of these ideas with events have some sort of manually managed stack-equivalent device, which is exactly what a green thread already is. So from there the benefits are around being able to use the sequential features of the language in combination (error handling, flow control, &c). Stackless transformations are a middle ground but there are plenty of things that become inconvenient without green thread stacks which make composition much easier.
      - zzzcpan 11y ago
        > which is exactly what a green thread already is. No, it's not. See my other reply. > there are plenty of things that become inconvenient without green thread stacks There are no such things. Because you can have all of the sequential code you want, but without any of the downsides of threads.
        strmpnk 11y ago
        I think we have different definitions then. A thread (green or not) is a context of execution which includes a stack. Saying that it's not what it is seems like you might be thinking of stackless generators or something, which are most certainly not green threads as it's a shallow control switch. I've spent plenty of time with both green threaded languages and non-green threaded languages. There is a most definitely a difference. A lot of the critiques you've given apply to event loops as well. For example, data access, sure you can't write half a value but interleaving callbacks for work broken up into multiple stages is just as complex in terms of interleaved flows and would require the same careful treatments you would need in threaded code. The solution there is not to share data, even with events. I'm sure you implicitly do this yourself but there is nothing that makes either better or worse at it. What you've failed to address are all of the trade-offs event loops have, like forgetful stack traces (and any effective fix keeps a stack of event flow contexts on the side, ironically). In reality neither green threads or event loops are all that amazing on their own. Great runtimes need a whole lot more, so it seems kind of silly to sit on one side of the fence shouting that there are no downsides on your side of things because there obviously are plenty of problems worth solving better in both camps.

auxym 11y ago

Why processes vs os-level threads?

learc83 11y ago
The OP said processes on dedicated cores, so I guess they meant you should use processes if you need fewer threads than you have available cores. If that is the case then processes could be faster than OS threads because you'd avoid context switches altogether. However, if your system supports pinning OS threads to processors and you limit the number of threads to the number of available processors, I can't think why that wouldn't be just as good.

zzzcpan 11y ago

> There are lots of problems that are trivial to solve with green threads/coroutines but that are very difficult without them. Name at least one that cannot be solved better without them.

rumcajz 11y ago
Network stacks. And pipelines in general.
- zzzcpan 11y ago
  Be specific. Network stacks and pipelines are easier even with the most basic event loop, because you simply don't have to think about concurrent memory access whatsoever. But you do with green threads and coroutines.
  - strmpnk 11y ago
    A lot of the edge cases like back pressure and certain kinds of state machines are a lot easier to represent as function calls rather than an asynchronous events. Most of the good implementations of these ideas with events have some sort of manually managed stack-equivalent device, which is exactly what a green thread already is. So from there the benefits are around being able to use the sequential features of the language in combination (error handling, flow control, &c). Stackless transformations are a middle ground but there are plenty of things that become inconvenient without green thread stacks which make composition much easier.
    - zzzcpan 11y ago
      > which is exactly what a green thread already is. No, it's not. See my other reply. > there are plenty of things that become inconvenient without green thread stacks There are no such things. Because you can have all of the sequential code you want, but without any of the downsides of threads.
      - strmpnk 11y ago
        I think we have different definitions then. A thread (green or not) is a context of execution which includes a stack. Saying that it's not what it is seems like you might be thinking of stackless generators or something, which are most certainly not green threads as it's a shallow control switch. I've spent plenty of time with both green threaded languages and non-green threaded languages. There is a most definitely a difference. A lot of the critiques you've given apply to event loops as well. For example, data access, sure you can't write half a value but interleaving callbacks for work broken up into multiple stages is just as complex in terms of interleaved flows and would require the same careful treatments you would need in threaded code. The solution there is not to share data, even with events. I'm sure you implicitly do this yourself but there is nothing that makes either better or worse at it. What you've failed to address are all of the trade-offs event loops have, like forgetful stack traces (and any effective fix keeps a stack of event flow contexts on the side, ironically). In reality neither green threads or event loops are all that amazing on their own. Great runtimes need a whole lot more, so it seems kind of silly to sit on one side of the fence shouting that there are no downsides on your side of things because there obviously are plenty of problems worth solving better in both camps.