在 TAP/TPL 之前，是否有处于阻塞状态的工作线程用于让出并 return 到旧线程池模型中的线程池？
Did a worker thread in blocking state used to yield and return to the threadpool in the old threadpool model before TAP/TPL?
请指正我的理解。
在引入基于任务的异步编程模型之前，.NET 线程池的工作方式有所不同。
1) 在旧系统下，当一个线程阻塞在 I/O 完成端口时，它是否在 CPU 完成端口上放弃了它的 CPU 时间片处于阻塞状态？
2) 我的理解是否正确，在 TPL 附带的新线程池和任务调度程序实现之后，现在线程 returns 在进入阻塞状态后立即进入线程池？
3) 而在旧制度下，被阻塞的线程没有返回到线程池，因此导致了本可以避免的不必要的线程注入开销？
1) Under the old system, when a thread was blocking on a I/O
completion port, did it yield its slice of the CPU time to the OS
while it was in blocking state?
是的。它基本上会在完成端口上调用等价物。注意 "WILL"。在这方面没有任何改变。
2) Is my understanding correct that after the new thread pool and task
scheduler implementation that came with TPL,
这里一点新意都没有。你从哪里得到错觉？ TPL建立在胎面池之上。它既没有改变它，也没有神奇地重写 KERNEL LEVEL SCHEDULER。
3) And that in the old regime, the blocked thread did not go back to the
thread-pool and hence caused unnecessary overhead of thread injection that
could have been avoided?
现在还是这样。您仍然可以自由使用标准 API。其他任何东西都建立在一些编译器技巧之上，使调用 API 更容易，但没有任何改变。还是有一些情况，旧的API更好。
所以，那部分是错误的。其余部分是正确的 - 线程在 returned 之前不能从池中使用。而标准线程 API 没有 return。新的两者都不做 - 线程 returned 到任务调度程序，任务调度程序在另一个任务上使用它，但从线程池方面来看，什么都没有改变。
请指正我的理解。
在引入基于任务的异步编程模型之前，.NET 线程池的工作方式有所不同。
1) 在旧系统下，当一个线程阻塞在 I/O 完成端口时，它是否在 CPU 完成端口上放弃了它的 CPU 时间片处于阻塞状态？
2) 我的理解是否正确，在 TPL 附带的新线程池和任务调度程序实现之后，现在线程 returns 在进入阻塞状态后立即进入线程池？
3) 而在旧制度下，被阻塞的线程没有返回到线程池，因此导致了本可以避免的不必要的线程注入开销？
1) Under the old system, when a thread was blocking on a I/O completion port, did it yield its slice of the CPU time to the OS while it was in blocking state?
是的。它基本上会在完成端口上调用等价物。注意 "WILL"。在这方面没有任何改变。
2) Is my understanding correct that after the new thread pool and task scheduler implementation that came with TPL,
这里一点新意都没有。你从哪里得到错觉？ TPL建立在胎面池之上。它既没有改变它，也没有神奇地重写 KERNEL LEVEL SCHEDULER。
3) And that in the old regime, the blocked thread did not go back to the thread-pool and hence caused unnecessary overhead of thread injection that could have been avoided?
现在还是这样。您仍然可以自由使用标准 API。其他任何东西都建立在一些编译器技巧之上，使调用 API 更容易，但没有任何改变。还是有一些情况，旧的API更好。
所以，那部分是错误的。其余部分是正确的 - 线程在 returned 之前不能从池中使用。而标准线程 API 没有 return。新的两者都不做 - 线程 returned 到任务调度程序，任务调度程序在另一个任务上使用它，但从线程池方面来看，什么都没有改变。