Silverlight and Networking – The UI Thread

23 Nov

The devil is in the detail as they say.  As Silverlight is essentially a client-based runtime, a large amount of resource will be invested in downloading data, posting data and generally interacting with resources external to the client.  This means frequent use of the WebClient or the associated WebRequest classes.

All of Silverlight’s APIs for interacting with resources on the web are async by nature.  This means that it looks by the design of the API that we can easily  do all our interaction on a separate thread and let the UI thread do it’s important rendering work.  However, as is always with Silverlight, all is not as it seems.  This is because even though Silverlight lets you do all the interaction on a thread other than the UI thread, the networking is ALWAYS marshalled back to the UI thread at some point in the networking stack.

What does this mean for me as a developer?
It means, that even though you have invested time and effort to keep the UI thread as empty as possible, the Silverlight runtime will execute networking operations back onto the thread that is in most applications, starved of resources.

Can we prove this?
Definitely.  Below I’ve included a solution to download which proves the point.  It allows the user to schedule (using Rx of course 🙂 ), every second, a web request to a local long running http handler.  The picture below shows this:

Clicking either the webclient or webrequest buttons will in an infinite loop, on the thread pool, download the result from a local HttpHandler.  Clicking the 3rd button will simply do a Thread.Sleep() on the UI thread.  If you hook up Fiddler, as required by the solution, you will notice that the web requests stop, and wait until the UI thread is released.  Once the UI thread has been released, all the queued web requests will all start executing and catch up.

What does this mean for me?
This should, in my opinion, be considered a bug in the runtime.  In my current role, we stream pricing data very quickly to our controls with the data being incredibly time sensitive.  Our UI is also very busy rendering some quite complex controls, animations and UI interactions.  If our UI is busy rendering frames, it means it cannot process network calls.  If it is busy processing network calls, it cannot process rendering requests. For busy, complex LOB Silverlight application this poses a very large problem for the developer.  How can we justify networking shuddering to a halt, because a large control is being rendered? The answer is that unfortunately, there is no answer.  We either have to slow down our networking calls, potentially caching if possible, or render less to the UI.

This bug exists in both Silverlight 3.0 and 4.0, and I definitely think the runtime requires a fix.  Is this a problem where the browser is imposing this restriction?  Is it a simple restriction that the runtime places on us as developers for some esoteric reason?

Thanks must go to the guys in the office, who came up with this simple test to prove the UI interaction in the networking stack.

Source code download

Advertisements

6 Responses to “Silverlight and Networking – The UI Thread”

  1. Ian 23/11/2010 at 23:10 #

    This has been extremely annoying especially given the announcement that Silverlight is now destined for smart devices. That is one problem that I notice with the Windows Phone 7 at the moment, whenever it is accessing the network then the pages stutter and fail to respond.

    Microsoft need to sort this one out because what is the point of a multi-threaded system if you put all of the strain on a single thread?

    • raybooysen 23/11/2010 at 23:11 #

      Completely agree. 🙂

  2. Gergely Orosz 03/12/2010 at 15:13 #

    Agreed, this is quite awful both in realtime systems and WP7 apps (note how the WP7 Facebook app lags until it finishes downloading content!)

    Luckily it will be fixed in SL5, however that won’t be out until summer and it still won’t be on WP7 😦

    • raybooysen 04/12/2010 at 12:23 #

      From what I’ve heard wp7 really suffers with this. Need to play more

  3. Gergely Orosz 21/03/2011 at 22:59 #

    I’ve just come across that this is supposedly by design: the WebClient does all the marshalling and un-marshalling of the data on the dispatcher thread. The WebClient is a wrapper around the HttpWebRequest class, which you can use to run on the background thread (and you’ll have to take care of calling the Dispatcher thread when updating the UI).

    Any thoughts on this?

  4. raybooysen 21/03/2011 at 23:10 #

    Well that is the crux of the problem. As a developer who does not know of this behaviour would dispatch multiple web calls on a background thread without expecting any interaction withe the UI thread. Suddenly his app starts performing badly and spends ages trying to spot the bug.

    I guess, it’s a bad implementation. If there is a technical requirement to be on the UI thread, I’d have expected this to be documented at some level so that devs would be made aware. This sort of hidden cost to the dev creates no benefit and just many many pain points.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: