The article is about .NET async/task and a driver hardware request specifically. I find the post title and article awful.
[…] we see that there was no thread while the request was in flight. When the request completed, various threads were “borrowed” or had work briefly queued to them. […] But there is no thread that was blocked, just waiting for that request to complete.
So there are threads after all.
Now, the path that we followed was the “standard” path, somewhat simplified. There are countless variations, but the core truth remains the same.
No, it doesn’t. You can’t take one specific use case and code flow analysis and extrapolate to a generic concept and universal truth. You can only make a statement for that type of thing. (And even then have to consider execution may differ for various reasons.)
The idea that “there must be a thread somewhere processing the asynchronous operation” is not the truth.
But the opposite of “there is no thread anywhere ever” is not true either.
For .NET tasks as a concept, an interface, tasks may return immediately not just without thread scheduling but also without task scheduling. Tasks may be scheduled through a thread pool. Or they may be executed like OP analysis.
They completely ignored anything outside their specific case and made a broad claim as if it represented all of them.
If the actual point is that “borrowed threads are not [real] threads” then that’s broadly misleading and wrong.
This is an essential truth of async in its purest form: There is no thread.
The objectors to this truth are legion. “No,” they cry, “if I am awaiting an operation, there must be a thread that is doing the wait! It’s probably a thread pool thread. Or an OS thread! Or something with a device driver…”
There is no thread waiting for the operation to complete is their point.
The article is about .NET async/task and a driver hardware request specifically. I find the post title and article awful.
So there are threads after all.
No, it doesn’t. You can’t take one specific use case and code flow analysis and extrapolate to a generic concept and universal truth. You can only make a statement for that type of thing. (And even then have to consider execution may differ for various reasons.)
But the opposite of “there is no thread anywhere ever” is not true either.
For .NET tasks as a concept, an interface, tasks may return immediately not just without thread scheduling but also without task scheduling. Tasks may be scheduled through a thread pool. Or they may be executed like OP analysis.
They completely ignored anything outside their specific case and made a broad claim as if it represented all of them.
If the actual point is that “borrowed threads are not [real] threads” then that’s broadly misleading and wrong.
There is no thread waiting for the operation to complete is their point.