.net - Task.Factory.FromAsync 和 RegisterWaitForSingleObject - 后者不会扼杀前者的用处吗？

Question

问题可以用 MSDN 的以下引述来描述:

The CommandTimeout property will be ignored during asynchronous method calls such as BeginExecuteReader.

在谷歌上搜索这个问题的解决方案时，我偶然发现了一些建议将 Task.Factory.FromAsync 与 ThreadPool.RegisterWaitForSingleObject 结合使用的帖子。

在SO上可以看看here和 here ，尽管这两个讨论的是异步 Web 请求，而不是 SQL 命令。但问题都是一样的 - 异步 SQL 命令/Web 请求超时。

建议的方法是调用 Task.Factory.FromAsync，然后调用 ThreadPool.RegisterWaitForSingleObject 等待或超时对应于任务的句柄。

这里有点不明白。异步 IO 方法利用 IO 完成端口回调来返回结果。当此类 IO 操作开始时，调用线程返回线程池以供其他请求重用。

另一方面，根据 MSDN:

The RegisterWaitForSingleObject method queues the specified delegate to the thread pool

和

The wait thread uses the Win32 WaitForMultipleObjects function to monitor registered wait operations.

这意味着它会阻塞线程池线程，直到我们的异步 IO 返回或发生超时。如果我的理解是正确的，那么如果我们使用这种技术，正在进行 N 个异步 IO 将阻塞和锁定 N 个线程池线程。

但是，在这种情况下使用异步 IO 有什么意义呢？所有 IOCP 优点都被 RegisterWaitForSingleObject 杀死。

另一方面，根据this MSDN blog , RegisterWaitForSingleObject 优化了等待，将来自同一线程的多个句柄批处理到对 WaitForMultipleObjects 的一次调用中，这反过来又限制了它可以等待的句柄数量 - 即64.

那么，如果每个请求从同一线程发出 65 个异步 IO 请求并结合 RegisterWaitForSingleObject，那么有多少线程池线程被(b)锁定？

Answer 1

So how many thread pool threads are (b)locked if 65 async IO requests are made from the same thread in conjunction with RegisterWaitForSingleObject per each request?

两个(对于 RegisterWaitForSingleObject 调用)- 每个 ThreadPool 线程可以处理 64 个请求(从技术上讲，它是 MAXIMUM_WAIT_OBJECTS 的值，实际上是 64)。

doesn't the latter kill the usefulness of the former?

没有。它确实降低了它的有效性，但由于 RegisterWaitForSingleObject 中有一个线程池，它不会破坏它的有效性。

请注意，在 C# 5 中，我通常会使用带有超时的 async/await 支持来处理这个问题。 Task.Delay 可以用来简单地处理这个问题，或者你可以制作一个 extension method using a Timer处理任何 Task 的超时。