4 ms·

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
          Ideally, the tasks would be serialized when dependent on each other and not when not dependent on each other. Dropping them on a queue discards information about the caller, which is what this thread of the discussion is about. Using greenlet or async/await, you can serialize only when necessary and retain information about the caller.