Welcome to MSDN Blogs Sign in | Join | Help

Caught red-handed!

I've been suspicious that a certain application that has been doing network access on their UI thread. (This is a horrible practice and anybody should be embarrassed doing it).  I tried to bring up some properties that I knew resulted in a ping to a server and the UI hung.

I waited. No UI. Still waited. No UI.

And then I turned off the network connection, which would cause network routines to return an immediate failure instead of hang indefinitely or wait for a very long timeout. (It's kind of like issuing a ThreadAbort to break out of an infinite loop). And the UI immediately sprang back to life.

Caught red handed!

Published Wednesday, April 05, 2006 11:56 PM by jmstall
Filed under:

Comments

# re: Caught red-handed!

Thursday, April 06, 2006 1:08 AM by Dean Harding
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.

# re: Caught red-handed!

Thursday, April 06, 2006 1:43 AM by chris-at
I hope the Explorer (Windows?) team reads this.

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

# re: Caught red-handed!

Thursday, April 06, 2006 2:39 AM by IDisposable
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!

Thursday, April 06, 2006 9:33 AM by Peter Ritchie
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.

# Testing network failures

Thursday, April 06, 2006 9:47 AM by Jeff Stong


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

# re: Caught red-handed!

Monday, April 10, 2006 11:21 AM by Jim Brechtel
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.

# re: Caught red-handed!

Monday, April 10, 2006 11:46 AM by jmstall
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.

# Questions you should ask before using a callback / delegate

Saturday, October 14, 2006 3:06 AM by Mike Stall's .NET Debugging Blog

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

New Comments to this post are disabled
 
Page view tracker