Scott Hanselman

I'm stuck in someone's for loop

October 24, '14 Comments [40] Posted in Musings
Sponsored By

This is a rant. More and more I'm finding myself using mobile devices, often on my iPhone, but also desktop applications in Windows and I'll push a button and find myself, as user, stuck inside your for loop.

Not Responding

Have you felt like this? The application locks up and you're stuck. Maybe it's Outlook saying Not Responding as the Curtain of Patience (tm) comes down, or perhaps it's Facebook on your iPhone updating Contact photos. Regardless, it's a for loop over a thousand or a million, or perhaps just one more data item than the developer tested, and you're stuck. Do you shut down and corrupt the data store? Do you wait? How long DO you wait?

Asynchronous programming can be hard, but the tools and languages support it, my friends.

Please don't block the UI.

Have you seen this? Why does it happen? What are you doing to avoid blocking calls? Perhaps it's a better UX pattern, or perhaps it's Reactive Programming?

Sound off in the comments!

Related Links


Sponsor: Big thanks to my friends at Octopus Deploy. They are the deployment secret that everyone is talking about. Using NuGet and powerful conventions, Octopus Deploy makes it easy to automate releases of ASP.NET applications and Windows Services. Say goodbye to remote desktop and start automating today!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Friday, October 24, 2014 10:49:15 PM UTC
Wwile(true) { BlockUI(); }
j j
Friday, October 24, 2014 10:49:35 PM UTC
While**
j j
Saturday, October 25, 2014 12:20:54 AM UTC
The trick to the many "Not Responding" issues of Outlook, is to stop using Outlook
Bob
Saturday, October 25, 2014 2:52:54 AM UTC
In my case, it's almost always making some kind of network call within some other transaction. Duh, I know I SHOULDN'T do that, but it's easy to miss this when you're in gotta-get-this-done mode and the networks these days are so fast and everything is working! You don't notice the mistake until it all explodes. And it always explodes SPECTACULARLY.

"Oops, I made that call to SmtpClient/SmartyStreets/FedEx inside of the database transaction." (Normally the e-mail is sent/address is validated/rate is returned quickly, so I never noticed, but when they or you have an outage, it hurts real bad -- all those transactions get blocked and pile up ... then deadlock, deadlock, tears, tears streaming down my face.

(You can extend this out to pretty much anything that you assume is "fast enough", though. A File.Open() works great on your machine but the call fails to return quickly on someone else's because whoops! the network share their file was on has achieved a higher state of entropy. I think only recently has the async everywhere mantra been driven home, really with just WinRT, so that's gonna take a while to come round....)
Nicholas Piasecki
Saturday, October 25, 2014 3:52:03 AM UTC
Have patience - it's getting better. Really. You're experiencing a feeling of inflated expectations from all the apps you use that have gotten good at async. When I feel that way I usually lie down for a spell.

Apps also have to be tested for all the operations that _might_ block the UI ... and that's hard to. Complex systems behave in unexpected ways - and something that was taking 100ms in 99.9% of cases might under rare conditions take 100x longer. Better tools might help with that.
Leo Bushkin
Saturday, October 25, 2014 6:20:29 AM UTC
Yeah Scott, like Leo says, go lie down for a spell. Lol.
James Makumbi
Saturday, October 25, 2014 6:53:59 AM UTC
The amount of asynchronous code I write has increased by huge amounts since I started using async/await in .Net. It's so stupidly easy that laziness can't justify not doing it. It's definitely my favourite platform/language feature.
Nacimota
Saturday, October 25, 2014 6:54:39 AM UTC
Has anyone noticed that if you momentarily look away from your screen whilst it's not responding, it has never recovered by the time you turn back, regardless of how long you give it.

While(user.CanWaitLonger) { BlockUI(); }
Daz
Saturday, October 25, 2014 7:40:39 AM UTC
Are you listening, Outlook team? :P
MichaelD!
Saturday, October 25, 2014 7:54:45 AM UTC
Use the event core pattern where all user interactions are translated to messages handled on another which then again can schedule long running ops or IO to tasks that reply with messages to the single threaded event core bus. Makes everything easier.
HarryDev
Saturday, October 25, 2014 7:55:22 AM UTC
another + thread
harrydev
Saturday, October 25, 2014 8:52:39 AM UTC
This is so frustrating, especially on desktop. I get so angry at outlook and visual studio at work. Visual studio especially seems notorious for it and I've no clue why. Maybe it's TFS communication, intellisense work of some sort, either way it's very annoying!
Howie Douglas
Saturday, October 25, 2014 10:09:08 AM UTC
It's a bit like all those web sites where you press Submit Order only to be greeted withPage Not Found or Page Cannot Be Displayed. Did my order go through? Can I refresh without resubmitting the order. If I press back, with my order go through?

On the desktop, I find that Windows is a bit quick to report Not Responding sometimes. I'm sure the amount of time you get to respond has reduced with successive versions of windows. Sadly, not everyone has the budget to rewrite large parts of their code to take advantage of Async/Await.
Saturday, October 25, 2014 12:58:58 PM UTC
We just have to *wait* for rx and rx.ui to take over the world (I think this is what that screen is suppose to say)
Saturday, October 25, 2014 2:47:21 PM UTC
On my machine this never happens. If it did I attach Windbg, take a memory dump and send it to the offender after I have analyzed the root cause.
Stop whining get better at debugging ;-). !analyze -v is not the end of a Debugging session.

Saturday, October 25, 2014 4:17:48 PM UTC
Fitting to this topic: My most loved feature in VS 2013 is also the most hated one: CodeLens - on my larger projects VS is "stuck" for several seconds every time it refreshes the lenses and uses 80-100% of ALL my 8 cores. If I wouldn't love the functionality of them so much I would have turned them of long ago...
Christoph
Saturday, October 25, 2014 8:55:58 PM UTC
There's still largely a design problem. Async isn't any better if you're executing a query on a server that returns a billion rows. Instead of the network layer chunking the response and passing it to the UI to render, it often has to wait for the entire transfer and then start processing. I know reactive solves that problem but people seem to just now grok async. How many more decades until Reactive is broadened where it needs to be? The problem also is largely adopted outside the .Net/Windows ecosystem where Reactive seems to be witchcraft.

This may sound like we're not progressing yet the space smartphones exist now are so totally different when "personal assistants" started us down the super tiny ultra portable computer path, but we still have a long way to go. That's really the exciting part of being a developer, something I can easily lose track of if I'm not reminded in posts like this.
Sunday, October 26, 2014 1:16:16 AM UTC
I think a couple of reasons. Maybe three.

Async/await is still pretty new, and a lot of devs are still learning it. WinRT helps by forcing devs to do it right instead of being lazy, but most other platforms don't. So, reason #1 is that a lot of devs just haven't learned async/await yet. And if you think the lack of async in UIs is bad, the lack of async on websites is far more extensive (in my experience).

Reason #2 is that async is hard on a lot of platforms. Sure, .NET has async/await, but have you ever tried it on JavaScript, Java, or Objective C? Proper asynchronous code is a *lot* harder. Considering JavaScript in particular (since it's everywhere now), it is getting async/await-like features in its vNext, but mobile app devs will have to wait a considerable time before async-enabled JS runtimes exist on the majority of mobile platforms. Until then, async is a real pain.

The third reason - which is kind of like reason #2 - is that backwards compatibility really throws a wrench in things. In particular, STA COM objects are all over the place in a lot of MS products including Office and VS. They have a thread affinity that many times *forces* you onto a UI thread.

IMHO. :)
Sunday, October 26, 2014 8:45:36 AM UTC
In particular, STA COM objects are all over the place in a lot of MS products including Office and VS.
That IS really a pain. We just created a new piece of software at work which is driving a hardware-device so a lot of IO is happening and we created it "async all the way", but at the end we where forced to "wrap a Sync-Layer on top" because we needed to support an old COM API...

In our UI we use async/await and for .NET also an "async-API" is available, but for that "old API support" we broke the "don't do sync over async"-rule (mostly using Stephen Toubs AsyncPump to avoid deadlocks) so we did not need to "duplicate most of the code/methods" by introducing a "sync-path" next to the async methods.
Christoph
Sunday, October 26, 2014 3:49:44 PM UTC
The most anoying non responsive UI i get too often, is Windows..

I get a SAVE FILE DIALOG, and choose to fold out the "my computer" to find a drive and then the UI locks up until all drives have responded.

The same thing happens too often when you open "My computer" to op en a drive.

Why not simply show drives that are ready and then show drives as they get ready ?
Martin Kirk
Sunday, October 26, 2014 6:23:00 PM UTC
Stop using Windows :) I don't know if OSX has a similar dialog, but if it does I've never seen it (after 4 years of using OSX).
Monday, October 27, 2014 12:37:47 AM UTC
The Walt Disney World sites fixed this problem. If it can't get the job done, it just returns a blank page, and nothing about your session ever works again. Genius, if you ask me.
Monday, October 27, 2014 10:54:39 AM UTC
One of the most unforgivable things I have seen very recently is in an old legacy application which uses a single persistent database connection with multiple result sets turned off. This means any multi threaded work in the UI is not possible. It means that when the very busy database is called by some method in the application and the database times out that the UI breaks or freezes out.

Its pretty unforgivable in modern applications, in older legacy applications that are hard to change because of shear weight of code its difficult to fix. So:

1) Address technical debt early
2) Don't block the UI
3) Don't block the UI

it really annoys me when the UI is blocked because of poor design. ARRRGHHHH.
Krystan Honour
Monday, October 27, 2014 12:51:46 PM UTC
Tweetdeck is one of the worst. I've watched whole episodes of Boardwalk Empire in the time it takes to release the UI.
John Dunagan
Monday, October 27, 2014 1:36:45 PM UTC
As others have said, async / await is newerish. A lot of places I have worked are stuck 2-3 version behind the current .NET version. The place I am working at now still uses .NET 2.0 and they are considering upgrading to 3.5, *maybe*.

Also, a lot of business folks don't see the benefit of refactoring code or spending time on maintaining. It's sad, but true.

$ > UX
Scott Vaverchak
Monday, October 27, 2014 1:52:26 PM UTC
Can I point out a case of *too much* async? I am a heavy keyboard user, and I regularly do something like Windows+R+notepad+enter and then I see a dialog box that says "Windows cannot find 'otepad'. Make sure you typed..." I'm tempted to create "otepad.lnk" and "md.lnk" A similar thing happens with entering my password on my Windows 8 machine. I have learned to "feel" the delay and tell if it dropped the first character of the password.

I am pretty sure this happens only when Windows hits the HDD (I am on an SSD too!). I just was able to repro, but only on the first try. I bet it will not happen for a few hours now.
Monday, October 27, 2014 2:51:56 PM UTC
This ranks right up there with other bad UI experiences:

"Script not responding, do you want to wait for it..." (no, 3 minutes before I got a response like this, no...)

"A pop-up is being blocked..." (No sh%^&t, that's why I installed a pop-up blocker, AD blocker, flash blocker, Google analytics opt-out, etc.)

Ranking WAY UP THERE in the Windows UI:

"The Flash of F&*^%ked Up-ness" (Do you wonder how much fun that would be to have Windows X as your vehicle operating system? Do you wonder how many accidents the FFoU would create? Seriously, do we need to flash the entire fricken screen if I'm already logged in as an Administrator?)

Copy-n-Paste from Win7 + has been a basket case. Using it between Win 8 and Hyper-V is laughable at best.

Don't get me started Scott :)
Monday, October 27, 2014 3:07:14 PM UTC
now you got me started ...

the endless Visual Studio 2013 prompt? "You have mixed spaces and tabs..." fix it, ..., ..., ignore and don't ask again

telling VS2013 to not ask again is like telling your 2 year old, "yes, we are REALLY out of ice cream :)
Monday, October 27, 2014 3:49:19 PM UTC
William - I run into that all. the. time.. I also hit it in Gmail when using keyboard shortcuts - I move most email to an Archive folder and I hit V -> type "Archive" -> Enter; it then prompts me to create a new label named "rchive".
Monday, October 27, 2014 4:14:38 PM UTC
Curtain of Patience ought to be a band.
marcus
Monday, October 27, 2014 4:38:08 PM UTC
I experience this behavior with Visual Studio more than any other app. It's working so hard to make sure I don't type something in wrong, that it won't let me type. I would rather have compile/runtime errors.
J.P. Hamilton
Monday, October 27, 2014 4:41:13 PM UTC
I must admit, I do get a little extra grumpy when (of all things) Visual Studio blocks the UI to tell me that it is "waiting for a background operation to complete"... If it's got to wait, it's not much of a background operation...
Andy Olson
Monday, October 27, 2014 9:28:17 PM UTC
9/10, Visual Studio blocks the UI because you started an action that needs dependencies resolved before it can complete, else upgrade your CPU.
Joseph Ohman
Monday, October 27, 2014 9:32:32 PM UTC
Worst program of them all like other point out. VS 2013. Restart about 5 times a day. Hangs quite often.
Einar
Tuesday, October 28, 2014 2:44:08 PM UTC
Visual Studio is very stable for me. Maybe you're running a bunch of extensions that may or may not be performant en masse?
Tuesday, October 28, 2014 6:02:24 PM UTC
Just to point out that if your application can't do anything else, nothing wrong with disabling the UI and throwing up an hourglass. I have seen soooooo many problems with people making sure the GUI thread doesn't hang (mostly on windows mobile) it becomes a far greater concern than the actual app.
Will
Tuesday, October 28, 2014 6:16:29 PM UTC
Just not blocking the UI doesn't solve the problem. The operation still has to complete, synchronously or not. Unless you also implement cancellation and progress, the user is still going to be stuck until you gracefully and asynchronously return control of the program.
Alex J.
Thursday, October 30, 2014 5:20:27 AM UTC
Aside from the problem of writing async code. When you have good async code, it's still a pain to test. We developers usually have state of the art machines, so things happen fast. So fast, that it is hard to test, so we may not encounter these oddities.

Chrome 38 has this new bandwidth/latency throttler under the new mobile testing view. It's not perfect, but it already helps to see how slow page loads work, and where async is done right. We need more easy tools to slow things down, and simulate normal user conditions. Or even better, we need a chaos monkey that occasionally makes some computational and IO operations really slow. :-)
Bart Verkoeijen
Thursday, October 30, 2014 10:10:38 AM UTC
The thing that really struck me when I moved from Windows to Mac OS X a couple of years back is that the UI basically always stays responsive. Microsoft themselves cannot even be bothered to ensure their apps respect the UI so I am not surprised third party developers can't either. It would seem to me that they need to make it easier for developers to do so as the creators of OS X clearly have.
Nik Southworth
Thursday, October 30, 2014 1:03:31 PM UTC
"Curtain of Patience" is ok, but I prefer "The Grey Mists of Doom"
This must of course be pronounced in a Scottish accent.
Huw Pendry
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.