mikeash.com pyblog/deconstructing-the-iphone-sdk-no-multitasking.html comments

mikeash - 2008-12-02 00:50:16

Tue, 02 Dec 2008 00:50:16 GMT

I wish people wouldn't bring up theoretical objections where they clearly don't apply. The halting problem only applies to automated determination of certain properties of a program with 100% accuracy. It does not mean that a human can't determine things to his satisfaction, and it does not mean that a computer can't place more restrictive limits, like, say, killing any background app that sucks up 100% CPU for more than five minutes straight.

If you're battery-conscious, don't allow background apps. (It would presumably be an option.) If you really want them, then monitor their resource usage and kill them if they misbehave. Not rocket science and hardly deserving of the "halting problem" treatment.

Mark - 2008-12-01 13:29:37

Mon, 01 Dec 2008 13:29:37 GMT

You say: "However, if you don't want runaway background apps killing your battery, don't run them."

How do you tell if an app is a "runaway?"

This is the fundamental problem of Computer Science: the Halting Problem.

Not so easy to solve.

mikeash - 2008-03-16 01:03:46

Sun, 16 Mar 2008 01:03:46 GMT

Well, if you count timers as events then any OS already restricts activity to be in response to events. I can see where they might want to make things more restrictive than usual, but it seems like they ought to have done that already instead of forcing everyone to be foreground-only if that's the case.

Chris Adams - 2008-03-15 11:19:29

Sat, 15 Mar 2008 11:19:29 GMT

My suspicion is that the people lobbying on for performance (and probably AT&T worries about network usage) have won temporarily and this feature will arrive when the OS becomes smart enough to do things like not only throttle CPU/memory/network activity but also do things like requiring activity to be in response to events (incoming packets, timer, etc.).