Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> To the point that even the stack size of green "threads" is known ahead of time.

This is only possible by not having stacks for those "green threads" (they're stackless coroutines, not stackful fibers/proper green threads).

It puts a severe limitation on the usefulness and forces any kind of recursive coroutine to heap allocate on returns.



One other obvious alternative would have been to make all futures heap-allocate so that some can be recursive.

I think making recursive futures invoke `Box` or similar seems consistent with Rust's general "only pay for what you actually use".


I disagree, because you're paying for boxing on return + dynamic dispatch when it's perfectly safe/sound to have a stackful coroutine that only allocates when the stack needs to grow and doesn't require dynamic dispatch. So you don't pay for heap allocated futures if they aren't necessary, and you pay less when they are.

So you're actually paying a higher price than if the compiler could support stackful generators for recursive futures. In fact async just gets a lot easier to write and use if generators could be stackful, at least imho. Generators don't have the syntax nice-ness of async/await, but they're also more explicit which feels more in with the rest of Rust, where syntax sugar like async/.await() is the exception and not the norm.


Fair enough, if we could create generators and futures that switch stacks that might work.


stackful coroutines break FFI


How so? You can swap stacks in posix just fine modulo some setjmp/longjmp shenanigans. But exceptions aren't sound across FFI either.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: