Linked by Thom Holwerda on Wed 30th Jan 2013 23:06 UTC
Permalink for comment 551151
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
2010-03-08
There are various types of background tasks that fire when a predefined trigger condition is met. Things like "User logs on", "User obtains internet", "AC power is plugged in" And other things like periodic updates as often as 15 minutes.
You can also do background audio and background file upload/downloading and executing a background task when receiving a push notification.
If you need to keep an underlying socket connection awake in the background, you can have up to 7 apps which do this in the background and provide real time communication.
(...)
I don't disagree that there is much to do here. I think its a significant step forward for Windows 8, but it's far from ideal for a variety of scenarios.
Looking forward, I'm sure WinRT will be improved to support a wider range of situations in which background processing is useful.
I'm sure there will always be corner cases that are missed, but I think this addresses a decent number of use cases.
Is there also support for "pure" background processing tasks, such as computing a 3D render or encoding a video ? OSs that go the whitelisting route often have issues with this basic scenario, and it is certainly annoying to have to keep staring at a progress bar out of fear that if you hide a productivity application, it will stop doing its job.
Maybe I just need to save the current page, and the value of a single scrollbar.
That is true, but it is to be expected that not every developer will bother to go through his whole codebase, looking for every bit of state which he can find, deciding what to save and what not to save, and then centralizing pointers to everything in one place and serializing everything.
In the event when someone would not do that, the OS should provide a reasonably graceful fallback, such as swapping the application's address space out when RAM gets full, and waiting until both RAM and swap space are full before starting to kill off stuff to free up space.
Developers are forced to be mindful of what they save, when they save it.
It seems strange to put strong constraints on suspend times, since it is not something which users actually experience. Sometimes, saving more data right now allows one to resume more quickly later, especially when that data is very expensive to regenerate (typical example being a heavy webpage loaded over an EDGE network connection).
Then again, if there were no restrictions on suspend times, you could achieve a similar effect in a simpler way by having the "suspending" thread run at a low priority, both from a CPU and I/O scheduling point of view.
The way you do it reminds me of how I'm basically reinventing pre-emptive multitasking on a work project, because the programming environment that we use has a mostly synchronous API coupled with a totally brain-dead multithreading implementation.