3 ms·

It’s not the only reason. For me, async code is easier to debug and understand because it is composed of regular functions (tagged with async). This means if

It’s not the only reason. For me, async code is easier to debug and understand because it is composed of regular functions (tagged with async). This means if you have a function that is 10 layers deep, you can pause the debugger and see the stack context. Same with your IDE, you can jump to each function. With threads that 10 function stack would be 10 threads, each requiring some sort of tooling at both software write time and runtime to get the context. In summary composing a system of just “functions (sync + async)” is easier than vs “functions + threads”

gpderetta 6y ago
hum, I'm missing something. The same call stack you get with async would map to exactly one thread call stack. Sure each thread will get its own call stack, but all related continuations that participate in an async call stack would be owned by the same thread (Assuming the same application design).
- justsomeuser 6y ago
  My point is that with async both the runtime and the dev tools try to make async call stacks look exactly like sync ones. This keeps the context of how your code gets into certain states. If you have 10 threads, it’s like you have 10 different processes (without the context of how they are related - which you get with composing functions) which is harder to understand. Also assuming that each thread does not have an event loop.
arethuza 6y ago
"With threads that 10 function stack would be 10 threads" Presumably only if you have one-thread per function - which I guess you could do but not sure if anyone actually writes multi-threaded code that way.
- justsomeuser 6y ago
  If you wanted each function to wait for IO or an event without blocking a thread you need an event loop, or one thread per function that needs to block to wait on incoming events.
  - arethuza 6y ago
    Well, I guess that is possible but I've never seen multithreaded server side code (in a thread per request type environment) bother - database calls or other IO just block the current thread.
justsomeuser 6y ago
If you down vote tell me how I’m wrong - appreciated!
- anonymoushn 6y ago
  If you had a thread-per-request, you would see the whole call stack for the request in your debugger, like you do now with async/await and an event loop. If you had a greenlet-per-request and an event loop, you would see the whole call stack for the request in your debugger, like you do now with async/await and an event loop.
  - justsomeuser 6y ago
    This is true, but: 1. If you are building the web server, the async stack would have the functions of the web server code too. The thread only sees its history from when it was spawned for that request. 2. As an example, if you needed to start 5 async tasks and await them, the async code would keep caller context if you break inside the task. For the thread-request model, you start new threads for each 5 tasks, if you debug-break in those threads you would not get the caller stack context. Or do you?
    - anonymoushn 6y ago
      To be honest, most people writing threaded code just let the 5 tasks run serially. Otherwise they would have the problem you mentioned.
      - arethuza 6y ago
        If there are dependencies between those tasks (i.e. task 2 depends on the result of task 1, task 3 depends on the result of task 2...) what option do you have? And if there aren't dependencies better to drop messages on a queue and have a completely different process handle those tasks.
        anonymoushn 6y ago

gpderetta 6y ago

hum, I'm missing something. The same call stack you get with async would map to exactly one thread call stack. Sure each thread will get its own call stack, but all related continuations that participate in an async call stack would be owned by the same thread (Assuming the same application design).

justsomeuser 6y ago
My point is that with async both the runtime and the dev tools try to make async call stacks look exactly like sync ones. This keeps the context of how your code gets into certain states. If you have 10 threads, it’s like you have 10 different processes (without the context of how they are related - which you get with composing functions) which is harder to understand. Also assuming that each thread does not have an event loop.

arethuza 6y ago

"With threads that 10 function stack would be 10 threads" Presumably only if you have one-thread per function - which I guess you could do but not sure if anyone actually writes multi-threaded code that way.

justsomeuser 6y ago
If you wanted each function to wait for IO or an event without blocking a thread you need an event loop, or one thread per function that needs to block to wait on incoming events.
- arethuza 6y ago
  Well, I guess that is possible but I've never seen multithreaded server side code (in a thread per request type environment) bother - database calls or other IO just block the current thread.

justsomeuser 6y ago

If you down vote tell me how I’m wrong - appreciated!

anonymoushn 6y ago
If you had a thread-per-request, you would see the whole call stack for the request in your debugger, like you do now with async/await and an event loop. If you had a greenlet-per-request and an event loop, you would see the whole call stack for the request in your debugger, like you do now with async/await and an event loop.
- justsomeuser 6y ago
  This is true, but: 1. If you are building the web server, the async stack would have the functions of the web server code too. The thread only sees its history from when it was spawned for that request. 2. As an example, if you needed to start 5 async tasks and await them, the async code would keep caller context if you break inside the task. For the thread-request model, you start new threads for each 5 tasks, if you debug-break in those threads you would not get the caller stack context. Or do you?
  - anonymoushn 6y ago
    To be honest, most people writing threaded code just let the 5 tasks run serially. Otherwise they would have the problem you mentioned.
    - arethuza 6y ago
      If there are dependencies between those tasks (i.e. task 2 depends on the result of task 1, task 3 depends on the result of task 2...) what option do you have? And if there aren't dependencies better to drop messages on a queue and have a completely different process handle those tasks.
      - anonymoushn 6y ago