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!
Don't blame my employer(s)... all of this is my fault.