Silverlight异步API导致挂起和无响应

发布于 2024-08-20 07:02:29 字数 534 浏览 5 评论 0原文

此代码会导致 silverlight 挂起。如果我删除 ManualResetEvent 代码，则不会发生任何情况

        private ManualResetEvent mre = new ManualResetEvent(false);

        ...

        WebClient sender = new WebClient();
        sender. += new OpenReadCompletedEventHandler(this.ReadComplete);
        sender.OpenReadAsync(new Uri(this.url+"?blob="+BODY, UriKind.Relative));

        mre.WaitOne();

    }
    public bool T = false;
    public void ReadComplete(object sender, OpenReadCompletedEventArgs e)
    {

        mre.Set();
    }

原文

this code causes silverlight to hang. If I remove the ManualResetEvent code, nothing happens

        private ManualResetEvent mre = new ManualResetEvent(false);

        ...

        WebClient sender = new WebClient();
        sender. += new OpenReadCompletedEventHandler(this.ReadComplete);
        sender.OpenReadAsync(new Uri(this.url+"?blob="+BODY, UriKind.Relative));

        mre.WaitOne();

    }
    public bool T = false;
    public void ReadComplete(object sender, OpenReadCompletedEventArgs e)
    {

        mre.Set();
    }

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

友欢 2024-08-27 07:02:29

您不能阻塞 UI 线程（参见“mre.WaitOne”）。如果您绝对需要 WaitOne，则必须在单独的线程中运行代码。这可以按如下方式完成：

var t = new Thread(delegate()
{
    //...
    mre.WaitOne();
    //...
});

人们期望回调中的“mre.Set()”将被触发。但是，我遇到了同样的问题，所以显然，OpenReadAsync 回调机制使用 UI 线程作为中间调度程序。该调度无法发生，它正在等待事件设置。

You cannot block in the UI thread (cf. "mre.WaitOne"). If you absolutely need the WaitOne, you must run your code in a separate thread. This can be done as follows:

var t = new Thread(delegate()
{
    //...
    mre.WaitOne();
    //...
});

One would expect that the "mre.Set()" in the callback would be triggered. However, I've had the same problem, so apparently, the OpenReadAsync callback mechanism uses the UI thread as intermediate dispatcher. That dispatching cannot happen it is waiting for the event to be set.

回复收藏 0 原文

渡你暖光 2024-08-27 07:02:29

我认为只有几个原因可能会让您相信您需要这种阻塞等待。您可能不知道应该在完成事件中继续使用您的代码，或者您有其他未包含在 ReadCompleted 过程无权访问的示例代码中的本地状态。

这是一些用于处理下载流的样板代码：-

string dummy = "Some value"; // local value you still need to access when download complete

WebClient wc = new WebClient();
wc.OpenReadCompleted += (s, args)
{
   if (!args.Cancelled)
   {
     try
     {
         Stream stream = args.Stream;  // This is the data you are after
         // Do stuff with stream, note the dummy variable is still accessible here.
     }
     catch (Exception err)
     {
         //Do something sensible with the exception to make sure its surfaced
     }
   }
};
sender.OpenReadAsync(new Uri(this.url+"?blob="+BODY, UriKind.Relative));

There are only couple of reasons that I can see that might lead you believe you need this blocking wait. Either you are not aware that you should continue with your code in the complete event or you have other local state that you haven't included in your sample code that the ReadCompleted procedure doesn't have access to.

Here is some boiler plate code for handling a downloaded stream:-

string dummy = "Some value"; // local value you still need to access when download complete

WebClient wc = new WebClient();
wc.OpenReadCompleted += (s, args)
{
   if (!args.Cancelled)
   {
     try
     {
         Stream stream = args.Stream;  // This is the data you are after
         // Do stuff with stream, note the dummy variable is still accessible here.
     }
     catch (Exception err)
     {
         //Do something sensible with the exception to make sure its surfaced
     }
   }
};
sender.OpenReadAsync(new Uri(this.url+"?blob="+BODY, UriKind.Relative));

回复收藏 0 原文

~没有更多了~