In an earlier post, I discussed my interest in Silverlight as a means to off-load CPU-intensive processing to web client machines, which are often just sitting around parsing angle brackets and not much else.

The idea is to do some work on background thread(s), so your Silverlight-enabled browser UI remains responsive, but you still get the benefits of doing less work on the server.

Turns out you can indeed spin up background threads in the Silverlight CLR, but there's currently no good way to marshal UI updating behavior from a background thread to the UI thread... ala Control.Invoke() in Windows Forms.

The "best" solution for now seems to be to maintain some shared (non-UI) state between your threads.  You update the state from a background thread upon completion of some long-running task; meanwhile, from the main UI thread, you periodically check (through use of HtmlTimer, a decidedly low-rez timer component) if the state has changed and when it does, update your UI.  It's inelegant and tedious, but it more or less works. 

I worked up a quick demo... you can get it here.  Note that you'll need Orcas Beta 1, Silverlight 1.1 alpha, etc. to make this work.

I've heard that the Silverlight team plans to provide a high-resolution timer in a forthcoming release... this will help, but frankly I think they should go one step further and implement some type of thread dispatching behavior, so we can avoid these kinds of hacks.

Silverlight isn't just about UI glitz and glamour... we can get some Real Work Done with this thing, given the right tools.  C'mon, Microsoft... help us out!

I've been poking around with the Silverlight 1.1 alpha release bits lately. My interest is probably a bit different than most folks... the whole RIA thing is certainly very interesting, but I'm exploring the idea of using .NET in the browser to enable background processing scenarios for web apps.

My company builds financial apps that do long-running, CPU-intensive calculations. These are typically rich client, Windows-based applications. Recently, we've begun exploring how to move some of our core processing functionality into web applications, and distribute it to a larger audience. Now, it's one thing to scale server software (even with CPU-intensive work) for a few users... it's another thing entirely to have hundreds of users hammering away on your server infrastructure.

I've explored some options for scaling our processing out, using dedicated server farms and well-known distributed processing architectures... there are caching and latency issues there, as well as deployment and configuration concerns. But those are solvable problems.

But once I saw Silverlight, I immediately started thinking beyond the fancy UIs and about how we can leverage that browser-based runtime for doing real background work. This allows us to offload work from the server, and localize it to its point of origin... so users who initiate lots of processing through their own actions are themselves paying the "CPU tax", and users who do little processing don't pay the price.  Woohoo server scalability!

Okay... so I started working on some simple Silverlight prototypes for doing background processing. System.Threading is there in almost its entirety... this is a Good Thing.  Very easy to spin up a thread, do some work, then synchronize back to the main UI thread. But now we've got a problem.

In Windows, you can't update your user interface from a background thread. Many windowing primitives (textboxes, etc.) use thread local storage to hold their state... so the thread the controls are created on (i.e. the main UI thread) is the only thread that has access to that state. This is a known problem that has existed in Windows programming for years. In .NET, we have a few mechanisms for dealing with it... BackgroundWorker is one, and the Control.InvokeRequired/Control.Invoke pattern is another. (As an aside, if you want to learn how to use these properly, you should sit in on DevelopMentor's Essential .NET class, which I happen to teach ).

So... back to the problem. I don't see BackgroundWorker or Control.Invoke/Required defined anywhere in the Silverlight version of the CLR! BackgroundWorker isn't really expected... it's fairly WinForms-specific. But no Control.Invoke and friends is a problem. So even though I can spin up a thread to do background processing in the browser, I can't update my UI as a result of that processing without resorting to hacks like this. Bah.

I know, I know... it's an alpha release. But System.Threading in Silverlight becomes significantly less useful without some easier means of accomplishing this. Anyone got any better ideas?