Catching up this morning as you can see. :) Here’s a good blog post about how Windows Phone handles multitasking. Contrary to the naysayers, it’s pretty sophisticated and entirely in keeping with Microsoft’s goal to hit the high points with this first release.
The new Windows Phone programming model uses a custom built Silverlight runtime to execute 3rd party applications … you write Silverlight apps that can’t access the system and, according to Microsoft, can’t even run in the background. Fortunately, applications aren’t quite that limited.
If an application is running and the user hits the Windows or Search buttons, the application is not (normally) terminated. Instead the OS places the app in a “suspended” state in memory. If the user later returns to the application either by restarting it or simply hitting the back button to dismiss the newer screens, the application resumes.
When an application is sent to the background, the foreground thread is suspended. However, any worker threads currently running in the suspended application continue to run. These worker threads can call base class library methods such as querying the file system, reading and writing files, and such even while the application is “suspended”.
When a worker thread tries to invoke a method on the foreground thread, that request is queued but not executed. When the application is resumed, the queued calls are invoked.
Of course, “suspended” applications live on borrowed time. If the system needs the memory used by the application it will be terminated.
So, while true multitasking doesn’t exist on the Windows Phone, applications can ‘borrow’ some background processing time as long as the system is lightly loaded. This sounds great and can be used to the advantage of the application. However, developers should understand this “feature” and if their applications have worker threads that don’t need to run while the application is suspended, they need to ensure that those “worker” threads block while the application is suspended.
Thanks to Robert Teague for the tip.
But that’s just an emulator bug. Applications need time to save state, and they are given this time, which is what is described here. Microsoft haven’t determined how much time applications will be given, and in the emulator background threads aren’t killed at all. This is supposed to change when a decision will be made.
There is no reason to believe this is an ‘emulator bug’. The emulator simply emulates an x86 machine that runs the WP OS image. The image itself is the same RC1Escrow image that has been unlocked by various sites.
As far as a time limit, I haven’t found one yet.
As I mentioned in my post, if it changes, it changes. However, I don’t see a reason for it to change right now.
Doug
The reason for it to change is that Microsoft said it would.
Pingback: Windows Phone and multitasking « Windows 7 Phone
If the OS is good about waiting for a apps worker threads to end before it kills it that’d be a nice balance I’d think. And honestly why not? We don’t know for sure and maybe lots of things they’ve said at MiX have changed due to feedback? I think we’ll know for sure when we get the final or near final OS emulator build before phones go out later this year. If that version still does it then I think it’s a safe bet that’s the case.