7 ms·
We already have stackful coroutines. They're called threads. If for some reason you want M:N threading, we have that too, via the mioco library. (If you think m
by pcwalton 8y ago
We already have stackful coroutines. They're called threads. If for some reason you want M:N threading, we have that too, via the mioco library. (If you think mioco's M:N threading will provide far superior performance to regular 1:1 threads, though, you will probably be disappointed.)
If you look at the performance numbers of these approaches, you'll see why stackless coroutines are desired.
- gpderetta 8y agoI want stackfull coroutines, with custom, fast user space scheduling and task switching with guaranteed optimisation to a single stack frame and no allocation where possible. I also want the ability to convert internal iterators to internal iterators with no overhead and even (especially) if the internal iteration function has not been specifically marked (i.e. no red/blue functions). Hey, a man can dream.
- eddyb 8y ago> guaranteed optimisation to a single stack frame and no allocation where possible You are literally describing stackless coroutines. And the generator state transform is that optimization. If you want to get this without using generators explicitly, it's still stackless coroutines just not how Rust supports stackless coroutines. There was some discussion about making it more implicit but no progress was made in the implicit direction.
- gpderetta 8y agoVery much not. I want first class stackful continuation semantics that behave as stackless in at least all (but ideally more) scenarios where a stackless continuation would.
- eddyb 8y agoI would also mention https://github.com/edef1c/libfringe https://github.com/edef1c/libfringe which pretty much solves context-switches (by replacing them with compiler-generated minimal stack spills/restores). But as you might be able to tell from their APIs, you still have to allocate stacks somehow.