I'm stuck in someone's for loop
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.
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
- Windows Phone 8 - Understanding Async and Awaitable Tasks
- Handling Asynchronous Data in Windows Store Apps
- PODCAST: Everything .NET programmers know about Asynchronous Programming is wrong
- The Magic of using Asynchronous Methods in ASP.NET 4.5 plus an important gotcha
- Async methods in ASP.NET 4.5
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.
About Newsletter
Hosting By
October 25, 2014 2:49
Wwile(true) { BlockUI(); }
j j
The trick to the many "Not Responding" issues of Outlook, is to stop using Outlook
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....)
"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....)
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.
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.
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.
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(); }
While(user.CanWaitLonger) { BlockUI(); }
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.
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!
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.
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.
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)
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.
Stop whining get better at debugging ;-). !analyze -v is not the end of a Debugging session.
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...
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.
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.
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. :)
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. :)
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.
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 ?
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 ?
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).
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.
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.
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.
Tweetdeck is one of the worst. I've watched whole episodes of Boardwalk Empire in the time it takes to release the UI.
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
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
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.
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.
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 :)
"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 :)
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 :)
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 :)
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".
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.
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...
9/10, Visual Studio blocks the UI because you started an action that needs dependencies resolved before it can complete, else upgrade your CPU.
Worst program of them all like other point out. VS 2013. Restart about 5 times a day. Hangs quite often.
Visual Studio is very stable for me. Maybe you're running a bunch of extensions that may or may not be performant en masse?
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.
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.
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. :-)
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. :-)
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.
"Curtain of Patience" is ok, but I prefer "The Grey Mists of Doom"
This must of course be pronounced in a Scottish accent.
This must of course be pronounced in a Scottish accent.
Comments are closed.