3 ms·
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
by 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 agoTo be honest, most people writing threaded code just let the 5 tasks run serially. Otherwise they would have the problem you mentioned.
- arethuza 6y agoIf 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 agoIdeally, 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.