5 ms·
The idea is that you have a small number of OS threads that have their own stacks and you cooperatively map all of the user-space greenlets onto these threads,
by DanWaterworth 15y ago
The idea is that you have a small number of OS threads that have their own stacks and you cooperatively map all of the user-space greenlets onto these threads, but whilst the greenlets are waiting to run, instead of storing their continuation as their stack and registers, you store the state as a closure. There's an obvious trade-off between responsiveness and memory usage, but you can adjust this by changing the number of OS threads.
So the stack frames aren't allocated on the heap.
- beagle3 15y agoAnd where exactly are those closures allocated?
- DanWaterworth 15y agoThey would be allocated on the heap, so mapping a greenlet onto an OS thread is a fairly expensive operation. However, the greenlets are cooperatively rather than pre-emptively mapped, so this doesn't happen as frequently as you may imagine.
- beagle3 15y ago> > > So the stack frames aren't allocated on the heap. > > So where exactly are the closures allocated ? > They would be allocated on the heap You're playing a weird game of semantics here. closures and stack frames are the same thing in this case. The fact that the "call stack" is implemented via a register called "the stack register" and uses a LIFO move-the-mark allocation scheme is an irrelevant implementation detail. Your assertion that CPS conversion is somehow more efficient than growable stacks is not supported by any of the arguments you presented.
- DanWaterworth 15y agoClosures and stack frames are definitely not the same thing. CPS conversion is used to create continuations; it's not necessary that the continuations are compiled naively using CPS.