Heavy workload background tasks in Metro: How to?

Can a user do heavy number crunching while his app gets pushed to the background when he temporarily switches to another app?

Automatic suspend would prevent this, so I looked into http://go.microsoft.com/fwlink/?LinkID=227329, but there it says clearly (p. 3):

"The background task execution environment is a restricted resource-managed environment and background tasks only receive a limited amount of CPU time."

So how do I implement complex database aggregate calculations or 3D rendering in the background, for example? In Metro, not the desktop, mind you.

Regards, Dirk.

Applications that need to do heavy background processing aren't suitable for the Metro environment and should be implemented as either as classical desktop applications or cloud-based applications with a lightweight Metro front-end.

Metro is not meant to be the be all and end all of application development and isn't suitable for every class of application.

You could design around it, so if your UI gets suspended, the computation keeps going.

2 hours ago, spivonious wrote

You could design around it, so if your UI gets suspended, the computation keeps going.

Not really, when a Metro app is backgrounded everything stops and the OS is free to kill it at will. You can request background jobs capability, but it's not going to be suitable for long term computation because Metro apps just aren't meant for that sort of thing.

3 hours ago, AndyC wrote

*snip*

Not really, when a Metro app is backgrounded everything stops and the OS is free to kill it at will. You can request background jobs capability, but it's not going to be suitable for long term computation because Metro apps just aren't meant for that sort of thing.

I agree with andy on this.

"Metro" is for apps that only run with the user is interacting with them or apps that do some processing and get messages.  Metro apps should be ones that can go to sleep or be halted by the system when it needs to.

do the number cunching and heavy lifting on a back end server and have a cloud service notify the app when new results are ready for use.

if the app really truly must do more then build a classic desktop app.

I absolutely see the point of giving the user that "fast and fluid" experience and to prevent apps from hogging up system resources. That's the right thing to do in a phone / slate environment.

But it also means that on a real PC, all you get is "apps", not real applications. Every time I want to do a simple database aggregate calculation in the background, I would have to resort to the desktop. Even though I see the potential of the UI for business applications, this kills Metro for LOB applications for me, if this is true.

I assume that the automatic suspend also holds for work items generated by ThreadPool::RunAsync to be executed by the thread pool?

Metro is still built on top of Win32, so you can still do work on background threads if you want to. There are obviously questions about whether that's a good idea, but it's certainly possible.

EDIT: Probably not in javascript though

Thx for all the feedback so far.

So if I summarize correctly:

By default, anything that takes more than 5 seconds to complete (the maximum time allowed for a deactivated app before entering suspend state) will be interrupted when the app is pushed in the background until the app is resumed / restarted. No multitasking for my app in the background there.

If I want to do some background processing other than audio playback or file upload/download (within WinRT !), I register my task with BackgroundTaskBuilder and have it executed by backgroundTaskHost.exe, a "restricted resource-managed environment" with "a limited amount of CPU time" (see the above whitepaper). Any information on how much CPU time the background task actually receives if, say, no other tasks are active and the user does not interact with the GUI?

Still unclear about how ThreadPool::RunAsync created tasks behave when the app is suspended. My best bet would be, they get suspended as well.

If I want to do heavy lifting in my Metro app, I have to "punch a hole" in the WinRT box my app lives in, either to Win32, to some server code or to the cloud. I guess it would be possible to implement the "server" on the same machine.

Honestly some of this has been with us for a *VERY* long time.

it has never been a good idea to have the UI take on jobs that are not directly interacting with the user.

for just one example look at how X-Window  defines "Server"   and allows for seperation between

"the process that talks to the screen and mouse"  and "the process that does the other stuff"

in X  the GUI is an "X-Server" and the backend stuff is the "CLient"

funny way to name them but in the end it's all seperation of concern and MVC ideas ....

and yes totally nothing wrong with (as long as metro allows for ) having say a windows service that you send commands to and a GUI that talks to the user.  I have done a ton of stuff this way for years.   when the GUI starts up it can start the service and when the GUI shuts down it can notify the service.

when needed the serivce can just keep running to finish work for the user and then shut it's self down when it has finished.

you can keep small log files in your database and when the GUI runs check on the status.

13 hours ago, evildictaitor wrote

Metro is still built on top of Win32, so you can still do work on background threads if you want to. There are obviously questions about whether that's a good idea, but it's certainly possible.

EDIT: Probably not in javascript though

No, you can't.

It might be built on top of Win32 but there are kernel level changes to process handling specifically to support Metro applications. Specifically when a Metro app is put into the background it is given a notification that it is about to be suspended, after two seconds all threads in the process are halted and all execution stops. If the kernel so decides it can terminate the process at any point from then on, or awaken it if the user foregrounds it again.

I strongly recommend anyone writing (or considering writing) Metro applications to go and what the BUILD video on when your application will run, because process lifecycles are very different to what they are under Win32 and if you don't understand it, your application will behave very oddly.

1 hour ago, figuerres wrote

and yes totally nothing wrong with (as long as metro allows for ) having say a windows service that you send commands to and a GUI that talks to the user. 

Metro doesn't allow IPC like this, or allow installation of Services for that matter.

1 hour ago, AndyC wrote

*snip*

Metro doesn't allow IPC like this, or allow installation of Services for that matter.

I use the database for most of that ....  service checks a set of tables and does what they tell it to do.

so the only thing is to have a non-metro app the user installs to hookup the service then.

mind you this is only for the stuff like the OP wanted. in general i would use a service as in a web/cloud service but if the data has to be local then ....

@figuerres: It would be a pretty appalling UX to require the separate installation of a desktop app just to get a Metro one working. And I'm not entirely sure if you can connect to a local server even via TCP/IP, so it might not even work then.

If you want the kind of app best suited to the desktop, just make a desktop application. It's really the only thing that actually makes sense. You can always style that to look like a Metro app if you really have to.

Yes, figuerres, locally. I have no problem with a PC connecting to the cloud or a phone/slate that never processes any major workloads by itself.

Maybe I still haven't completely gotten the philosophy behind Metro. I think many users and developers expect it to carve out some territory from the desktop realm.

Seems like a reasonable expectation from ANY app, not just Metro, to do background processing or finish some task with more than a "limited amount of CPU time" while inactive. Some would consider an architecture that does not allow for this broken, on a PC anyway. If resources are available, I would expect nothing less than for my background task to receive full CPU power, take away what is needed for the UI.

Thanks figuerres for the DB hack, but I would prefer clean and direct communication with my service, staying inside of my framework, in this case WinRT, all the time. In Win32 or with .NETs System.IO.Pipes I can stay in my framework and still communicate with a service.

I don't want to fail to propose a solution: give tasks created by BackgroundTaskBuilder full CPU power, evenly shared among apps that request it, and reserve enough for "fast and fluid"

@DirkAckermann: "Background tasks" get something like a couple of seconds every 15 minutes or so, it's intended merely to give apps that need to periodically poll old-fashion protocols like POP to check for status updates, it's not a general purpose solution.

Metro is not meant to "replace" the desktop, otherwise the desktop just wouldn't be there. In the future I fully expect WinRT will be extended into the desktop arena, but not in this release. Metro is geared primarily around cloud applications, where heavy work is done elsewhere and the client processing power is used primarily for output. Things like battery life are critical to mobile devices like laptops and tablets and, given these largely represent the future of the "PC", it makes more sense to avoid doing power hungry operations locally.

Makes sense for power sensitive devices, I see your point.

I think the Metro UI could be ideal for LOB applications. Business users typically get distracted by too much chrome.

In a perfect world I could give my user an option during install/ first run to connect to the cloud, to a backend server or to a local service for the heavy lifting. If only I could get that service going from within WinRT. Something for Microsoft to look into, I propose.