5 ms·

Network stacks. And pipelines in general.

by rumcajz 10y ago

zzzcpan 10y 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 10y 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 10y 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 10y 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.
      - zzzcpan 10y ago
        Thread from a programming perspective is pretty much anything, that shares memory and has an implicit context switching. Which is very different from other, mostly event-loop based, concepts, that don't give up control implicitly. It is very important not to mix them. Even something that looks like a thread, but can only switch context when there is a special keyword, is not a thread anymore, and unlike a thread is very precise of what can and cannot be executed out of order and access memory willy-nilly. I actually implemented a C-dialect DSL once, that did basically this, i.e. added to C reenterable functions with heap allocated context and an event loop to run them. I eventually abandoned the project and the idea, as synchronous code isn't that good to work with. Even Erlang's "synchronous" processes receive messages in an event driven fashion. I think you didn't have a pleasure to work with event loops in languages with first-class functions, that's why you think they are on the same boat with green thread. They are not, of course. There are no trade-offs. You have multiple scopes to share memory from, one for each handler, that can execute only atomically, one for all handlers created by that function, that may execute out of order, and a global scope of course. You can compose functions, give them names and what not. You can even have a console, like Erlang does. I've tried like a dozen of concurrency models, you cannot really convince me, that threads are any good for that.
- barrkel 10y ago
  Event loops lose your call stack; you need to rewrite your program as a state machine so you know where to pick back up; or you need to rewrite your program in continuation passing style with callbacks, like JavaScript; or you automate that CPS transform, and you've just reinvented green threads again.
  - Matthias247 10y ago
    I agree with what you (and the others) say. Regarding green threads and state machines I would however add that while green threads allow to ditch some state machines (e.g. ones that wait until a complete packet was received) you won't get rid of all of them, e.g. you will still need state machines for lots of protocol implementations. E.g. if you are implementing the websocket protocol or HTTP/2, you have some interaction between incoming data, data that must be sent out and requests from the [library] user. The state of the connection depends on all of these, so you need some kind of connection state machine which would run most likely in it's own green thread (in addition to a sending thread and a receiving thread and a user thread). And now you have to implement clean synchronization between all of those threads. The lack of necessary synchronization (and the ability to observe a huge amount of state at once without danger) can make the implementation a little bit more easy in my experience. But here I also have to agree with strmpnk that a good design is necessary for both approaches, and accessing lots of shared mutable data in multiple callbacks is probably also not the cleanest approach.
  - zzzcpan 10y ago
    There is a very big difference between implicit flow control, that you have with green threads and explicit one, that you have with "reinvented green threads", as you call them. First one will force you to think about synchronization to access your memory, but the second one - won't. It will also let you do clean cancellation, etc., that you won't be able to do with green thread.

Network stacks. And pipelines in general.

by rumcajz 10y ago

Network stacks. And pipelines in general.

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 10y 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 10y 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 10y 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.
    - zzzcpan 10y ago
      Thread from a programming perspective is pretty much anything, that shares memory and has an implicit context switching. Which is very different from other, mostly event-loop based, concepts, that don't give up control implicitly. It is very important not to mix them. Even something that looks like a thread, but can only switch context when there is a special keyword, is not a thread anymore, and unlike a thread is very precise of what can and cannot be executed out of order and access memory willy-nilly. I actually implemented a C-dialect DSL once, that did basically this, i.e. added to C reenterable functions with heap allocated context and an event loop to run them. I eventually abandoned the project and the idea, as synchronous code isn't that good to work with. Even Erlang's "synchronous" processes receive messages in an event driven fashion. I think you didn't have a pleasure to work with event loops in languages with first-class functions, that's why you think they are on the same boat with green thread. They are not, of course. There are no trade-offs. You have multiple scopes to share memory from, one for each handler, that can execute only atomically, one for all handlers created by that function, that may execute out of order, and a global scope of course. You can compose functions, give them names and what not. You can even have a console, like Erlang does. I've tried like a dozen of concurrency models, you cannot really convince me, that threads are any good for that.
barrkel 10y ago
Event loops lose your call stack; you need to rewrite your program as a state machine so you know where to pick back up; or you need to rewrite your program in continuation passing style with callbacks, like JavaScript; or you automate that CPS transform, and you've just reinvented green threads again.
- Matthias247 10y ago
  I agree with what you (and the others) say. Regarding green threads and state machines I would however add that while green threads allow to ditch some state machines (e.g. ones that wait until a complete packet was received) you won't get rid of all of them, e.g. you will still need state machines for lots of protocol implementations. E.g. if you are implementing the websocket protocol or HTTP/2, you have some interaction between incoming data, data that must be sent out and requests from the [library] user. The state of the connection depends on all of these, so you need some kind of connection state machine which would run most likely in it's own green thread (in addition to a sending thread and a receiving thread and a user thread). And now you have to implement clean synchronization between all of those threads. The lack of necessary synchronization (and the ability to observe a huge amount of state at once without danger) can make the implementation a little bit more easy in my experience. But here I also have to agree with strmpnk that a good design is necessary for both approaches, and accessing lots of shared mutable data in multiple callbacks is probably also not the cleanest approach.
- zzzcpan 10y ago
  There is a very big difference between implicit flow control, that you have with green threads and explicit one, that you have with "reinvented green threads", as you call them. First one will force you to think about synchronization to access your memory, but the second one - won't. It will also let you do clean cancellation, etc., that you won't be able to do with green thread.