3 ms·
The rationale for async/await I keep hearing is that the separate stack required for each thread uses a lot of memory. I’m not sure going full on function colou
by irdc 2y ago
The rationale for async/await I keep hearing is that the separate stack required for each thread uses a lot of memory. I’m not sure going full on function colouring is the answer though. A concerted effort for language runtimes to use less stack space and then simply allocating smaller thread stacks sounds to me like a more elegant solution. It certainly is a whole lot easier to debug than a deeply-nested async/await chain.
- iknowstuff 2y agoBut also avoiding the cost of context switching, and the ability to handle many tasks in embedded environments. https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
- irdc 2y agoThis makes it sound like using async/await is more like hand-optimising your code, somewhat similar to rewriting it in assembler. If a way can be found to improve thread switching times (eg. by only switching registers the program actually uses), the fact that the threaded code is easier to debug and reason about becomes a large advantage.
- throwuxiytayq 2y agoOnly in the same way that assembly is safer, more readable and easier to write than C. I’m not seeing significant improvements happening to the OS level threading model anytime soon, or ever really, at last in the context of existing mainstream operating systems.