DownloadStringAsync需要UI线程？ [英] DownloadStringAsync requires UI thread?

问题描述

  

可能重复：结果
  <一href=\"http://stackoverflow.com/questions/8466036/execute-a-webrequest-in-a-background-thread-while-ui-thread-is-blocked\">Execute而UI线程被阻塞

在后台线程的WebRequest

看看这个code：

 线程t =新主题（（A）=＆GT;
    {
        VAR的客户=新的WebClient（）;        client.DownloadStringAsync（新的URI（http://www.google.com））;        布尔pointB = TRUE;
    }）;t.Start（）;
t.Join（10000）;
 

当这是在Silverlight UI线程上运行，即使DownloadStringAsync（）被称为快速，pointB不会直到加入（）超时后到达。这意味着DownloadStringAsync（）必须以某种方式要求UI线程做其工作。 注意：此无关的的回调应用于DownloadString 。我知道，Web客户端的回调发生在UI线程（在这里看到：<一href=\"http://stackoverflow.com/questions/4326937/silverlight-background-thread-using-webclient\">Silverlight使用Web客户端）后台线程。

我的code的行为似乎表明，异步调用方法本身（DownloadStringAsync（））也需要UI线程。是对的吗？如果是这样，为什么呢？我也想指出此相同的行为使用 HttpWebRequest.BeginGetResponse（）

当展

编辑：把事情一清二楚，操作我看时，我通过这个code步骤的顺序是

1. t.Start（）


2. t.Join（10000）;


3. VAR的客户=新的WebClient（）;


4. client.DownloadStringAsync（新的URI（http://www.google.com））;


5. （...加入（）超时）


6. 布尔pointB = TRUE;

解决方案

好吧，我想我找到了答案多一点挖后。它似乎确实是所有网络code最终在UI线程上运行：
的http://nondestructiveme.com/2010/11/23/silverlight-and-networking-the-ui-thread/

好消息是，看来微软修复这个错误，因为你可能在调用它，在Silverlight 5是合理的：
http://msdn.microsoft.com/en-us/库/ gg986857（VS.95）的.aspx

（在根据性能改进页面的底部：
通过使用一个后台线程联网减少网络延迟，这对于使用客户端的HTTP Web请求的情况很有帮助。）

在我的测试Silverlight的5我的code，看它是否真的解决了该问题，我会修改这个答案。

编辑：内置反对的Silverlight 5，我仍然有同样的问题。我想，是时候让我放弃试图阻止UI线程在所有...

Possible Duplicate:
Execute a WebRequest in a Background thread while UI Thread is blocked

Check out this code:

Thread t = new Thread((a) =>
    {
        var client = new WebClient();

        client.DownloadStringAsync(new Uri("http://www.google.com"));

        bool pointB = true;
    });

t.Start();
t.Join(10000);

When this is run on the UI thread in Silverlight, even though DownloadStringAsync() is called quickly, pointB will not be reached until after the Join() times out. This means DownloadStringAsync() must somehow require the UI thread to do its work. Note: this has nothing to do with the callback to DownloadString. I know that WebClient's callbacks happen on the UI thread (see here: Silverlight Background Thread using WebClient).

The behavior of my code seems to indicate that the async invoke method itself (DownloadStringAsync()) also requires the UI thread. Is that right? And if so, why? I also want to note this same behavior is exhibited when using HttpWebRequest.BeginGetResponse()

Edit: to make things crystal clear, the order of operations I see when I step through this code is

1. t.Start()
2. t.Join(10000);
3. var client = new WebClient();
4. client.DownloadStringAsync(new Uri("http://www.google.com"));
5. (... Join() timeout)
6. bool pointB = true;

解决方案

Alright, I think I figured out the answer after a little more digging. It does seem indeed that all network code is ultimately run on the UI thread: http://nondestructiveme.com/2010/11/23/silverlight-and-networking-the-ui-thread/

The good news is it seems Microsoft fixed this "bug", as you might be justified in calling it, in Silverlight 5: http://msdn.microsoft.com/en-us/library/gg986857(VS.95).aspx

(At the bottom of the page under Performance Improvements: "Reduced network latency by using a background thread for networking. This is helpful for scenarios that use client HTTP web requests.")

I'll edit this answer once I test my code on Silverlight 5 to see if it indeed fixed the issue.

Edit: Built against Silverlight 5 and I'm still having the same problem. I think it's time for me to give up trying to block the UI thread at all...

这篇关于DownloadStringAsync需要UI线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！