Question

为什么以下代码在5秒后执行WebRequests时UI线程不再被阻止？ Thread.Sleep位于UI线程中，而WebRequest的实例化和调用都发生在ThreadPool的线程内。

Loaded += (sender, args) => {

    for (int i = 0; i < 5; i++) {

        ThreadPool.QueueUserWorkItem(state => {
            var request = WebRequest.CreateHttp("http://google.com");
            request.BeginGetResponse(ar => Debug.WriteLine("Request finished"), null);
        });

        Thread.Sleep(1000);
    }

};

在UI线程被阻止时，我应该编写什么代码才能在后台线程中执行WebRequest？

修改 ...更具体。为什么此请求在10秒后执行，因为在后台线程中？

Loaded += (sender, args) => {

    ThreadPool.QueueUserWorkItem(state => {
        var request = WebRequest.CreateHttp("http://google.com");
        request.BeginGetResponse(ar => Debug.WriteLine("Request finished"), null);
    });
    Thread.Sleep(10000);

};

Answer 1

我在这里问了几乎完全相同的问题（我现在关闭了，我发现你的问题）： DownloadStringAsync requires UI thread?

答案是所有网络代码最终都会在版本5之前封装到Silverlight中的UI线程。不幸的是，即使我针对Silverlight 5进行构建，我仍然会遇到同样的问题，所以我还在调查......

Answer 2

也许你的意思是这样做：

Loaded += (sender, args) =>
{
    ThreadPool.QueueUserWorkItem(dummy =>
    {
        for (int i = 0; i < 5; i++)
        {

            ThreadPool.QueueUserWorkItem(state =>
            {
                var request = WebRequest.CreateHttp("http://google.com");
                request.BeginGetResponse(ar => Debug.WriteLine("Request finished"), null);
            });

            Thread.Sleep(1000);
        }
    });

};

这根本不会阻止UI，并且Debug消息每秒都会出现。或者你想要的行为是什么？你真的想阻止UI（你不应该......）？

编辑（编辑后）：

我明白了。这是违反直觉的，我没有立即回答。我强烈怀疑该请求需要一些UI线程活动。你的主线程应该总是响应，永远不会阻止所以这没有问题。除非你阻止主线程。因此，他们可能不遗余力地优化有缺陷的案例（这是）。

然而，答案很有趣。我从桌面世界知道浏览器相关的东西需要主线程。所以我建议不再阻止它：）

在UI线程被阻止时，在后台线程中执行WebRequest

2 个答案: