Caught red-handed!

Questions you should ask before using a callback / delegate

Mike Stall's .NET Debugging Blog — Sat, 14 Oct 2006 10:06:40 GMT

I just got burned by using callbacks in a multi-threaded app. I've rewritten the part to avoid callbacks,

re: Caught red-handed!

Mike Stall - MSFT — Mon, 10 Apr 2006 18:46:10 GMT

Jim B - we totally agree that *background worker threads* (that aren't blocking the UI) are the right way to go.

The problem here is using the *UI thread*. Thus the entire UI blocks while the UI thread is off pinging a server.

re: Caught red-handed!

Jim Brechtel — Mon, 10 Apr 2006 18:21:35 GMT

Most web applications, especially browsers (any browser, not just IE) will use multiple simultaneous background threads to connect to a server and download content. There is absolutely nothing wrong with this. In fact, if they did not use threads, your web application would operate much slower and you would see both text and graphic fields slowly populate one at a time.

Unless the application is spyware or doing something malicious, why would using a background thread be an issue? It's a matter of choice. Either make the web application multi-threaded or else use a single thread and wait longer for it to get its work done.

Testing network failures

Jeff Stong — Thu, 06 Apr 2006 16:47:22 GMT

Mike
Stall points out why doing network access on a UI thread is a horrible
practice.&nbsp; He...

re: Caught red-handed!

Peter Ritchie — Thu, 06 Apr 2006 16:33:52 GMT

Technically, all applications I've ever seen do network communications on the UI thread--when they access a file over the network.

Maybe a nice tidy reference implementation? As you say in your previous post, anything that could take any amount of time should be done in a background thread. It's a bit more detailed then that though; you're not suggesting the application become multi-threaded, just potentially-long-running tasks be done in another thread. So, the application has to either be smart about synchronization if going the full MT route; or smart about turning off UI features (and providing feedback/progress) while it waits for the background thread to complete so synchronization is not an issue while the UI is responsive.

I would hazard to say that most people reading this blog already know how to do what you're suggesting; but, some guidance (reference implementation(s)) for those who don't (or are to lazy) goes a long way.

It doesn't help much when 99.99% of the samples on MSDN dealing with this topic do it the wrong way. Usually samples that could block a UI are done in a console app to avoid the complexity of "doing it right". But, MSDN is the cookie-cutter code that most apps inherit from.

re: Caught red-handed!

IDisposable — Thu, 06 Apr 2006 09:39:57 GMT

The absolute WORST culprit for this is Explorer handling the pop-up window for viewing/selecting available Wireless Networks. How stupid is that?

re: Caught red-handed!

chris-at — Thu, 06 Apr 2006 08:43:50 GMT

I hope the Explorer (Windows?) team reads this.

I've been waiting since Windows 95 for them to fix that.

re: Caught red-handed!

Dean Harding — Thu, 06 Apr 2006 08:08:14 GMT

Outlook is horrible for doing network access in the UI thread. It's not so bad when your just connecting with a POP3 account, but when you're connected to Exchange, it can sometimes be an aweful experience.

In Outlook 2003, they added that little notifcation icon thing (being able to minimize Outlook to the notification tray is an awesome feature). When the UI thread of Outlook becomes unresponsive, the little notification icon pops up a balloon which says something like "please wait, there may be issues with your Exchange server which prevents Outlook from displaying it's UI". What's wrong with that picture, I wonder?

Explorer is another one for doing the same thing. It's horrible when a network drive goes down and Explorer just sits there being unresponsive for up to a minute until it times out.