c# - 深入理解 ASP.NET MVC 上的 async/await

Question

当我在 MVC Controller 上执行异步操作时，尤其是在处理 I/O 操作时，我不明白幕后到底发生了什么。假设我有一个上传操作:

public async Task<ActionResult> Upload (HttpPostedFileBase file) {
  ....
  await ReadFile(file);

  ...
}

据我所知，这些是发生的基本步骤:

1. 从线程池中查看一个新线程并分配它来处理传入请求。

2. 当 await 被命中时，如果调用是一个 I/O 操作，那么原始线程将返回到池中，控制权将转移到所谓的 IOCP(输入输出完成端口)。我不明白的是为什么请求仍然存在并等待答复，因为调用客户端最终会等待我们的请求完成。

我的问题是:谁/何时/如何等待完全阻塞发生？

注意:我看到了博文 There Is No Thread ，它对 GUI 应用程序有意义，但对于这个服务器端场景，我不明白。真的。

Answer 1

网络上有一些很好的资源对此进行了详细描述。我写了一个MSDN article that describes this at a high level .

What i do not understand is why the request is still alive and waits for an answer because in the end the calling client will wait for our request to complete.

它仍然存在，因为 ASP.NET 运行时尚未完成它。完成请求(通过发送响应)是一个明确的 Action ；请求不会自行完成。当 ASP.NET 发现 Controller 操作返回 Task 时/Task<T> , 在该任务完成之前它不会完成请求。

My question is: Who / when / how does this wait for complete blocking occurs ?

没有什么是等待。

这样想:ASP.NET 有一个正在处理的当前请求的集合。对于给定的请求，一旦完成，就会发出响应，然后从集合中删除该请求。

关键是它是请求的集合，而不是线程。这些请求中的每一个在任何时间点都可能有也可能没有线程在处理它。同步请求总是有一个线程(同一个线程)。异步请求可能有没有线程的时期。

Note: i saw this thread: http://blog.stephencleary.com/2013/11/there-is-no-thread.html and it makes sense for GUI applications but for this server side scenario I don't get it.

I/O 的无线程方法对于 ASP.NET 应用和 GUI 应用完全一样。

最终，文件写入将完成，这(最终)完成了从 ReadFile 返回的任务.这种“完成任务”的工作通常是用一个线程池线程来完成的。由于任务现已完成，Upload action 将继续执行，导致该线程进入请求上下文(也就是说，现在有一个线程再次执行该请求)。当 Upload方法完成，然后任务从Upload返回完成后，ASP.NET 写出响应并从其集合中删除请求。