3 ms·

What is the fundemental problem we are trying to solve here? My pet problem with async is that it takes so much syntax, and i wonder why we need to do that. As

What is the fundemental problem we are trying to solve here? My pet problem with async is that it takes so much syntax, and i wonder why we need to do that. As i understand it it is all about blocking calls taking up OS threads. So i will try to naievly solve it here, and maybe i end up with the same conclusions. When doing a blocking call, the OS thread could just start executing something else transparently and not 'yield' anything to the code, it just stops executing the code and comes back and executes further, no await, no tasks no nothing. Ok, but how did we end up in a thread? The http listener started 4 threads and it's just putting a stack of function pointers and context memory for the threads to eat when they want. There is a separate engine on another OS thread that handles where the threads can start executing ready code again. No Task or await keywords show up in this code. I have no idea how stack traces work but i guess that can just be saved to memory and loaded back again when the threads feel like executing some ready code

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 ago
  But 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 ago
    This 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 ago
      Only 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.
layer8 2y ago
What you propose is similar to how Java virtual threads work.
- ikekkdcjkfke 2y ago
  Thanks for pointing me in right direction. That's exactly what I'm wishing for in .net
jayd16 2y ago
Ok well OS threads are already scheduled this way... The drawback is they're heavier because they make assumptions that the runtime doesn't need to make. Furthermore, explicit Async/await provides a syntax for co-opoerative multithreading and that enables other patterns that implicit designs don't.

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 ago
But 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 ago
  This 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 ago
    Only 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.

layer8 2y ago

What you propose is similar to how Java virtual threads work.

ikekkdcjkfke 2y ago
Thanks for pointing me in right direction. That's exactly what I'm wishing for in .net

jayd16 2y ago

Ok well OS threads are already scheduled this way... The drawback is they're heavier because they make assumptions that the runtime doesn't need to make. Furthermore, explicit Async/await provides a syntax for co-opoerative multithreading and that enables other patterns that implicit designs don't.