Loopt for Android... with background location!
nytimes.com
nytimes.com
My own little Android app (http://phonalyzr.com) is another example. Rather than background processing, it needs access to contact/call log info. On Android and BlackBerry the OS notifies the user the app will access that and the user can make a decision, on the iPhone that decision has been made for the user by Jobs.
When people start to see stuff like Loopt working better on Android or similarly open devices and when none of Jobs' scare tactics (malicious apps, viruses bringing down networks etc) come to pass, perhaps the iPhone will open up a bit more.
Background processes are a big win and would be a huge factor for me, but I'd need to see some improvement of handset design before I'm ready to switch.
The real question is when will we see a more polished Android phone?
Android handsets definitely lack a certain polish, both software and hardware side. Its quite a pickle.
They just implement preemptive multi threading, that way if some threads need more and some need less, they all get the CPU they need. (well, in general).
In fact the API you suggest seems needlessly complex Why a "VM"? Why register callbacks? Just let tasks run without a UI thread. Let the process with the currently visible UI thread have priority. Simple, done. (Glossing over the fact that doing things the way Apple does it allows for them to make better performance and battery-life guarantees, which is something not solved with your API as the user "cost" is taken out on other applications generally, as users don't know that their battery is worse because of you, or that there browser doesn't scroll as smoothly because of your bad background thread.)
An app that uses GPS could tie into the time of day and week and change its polling frequency based on a pattern of past movement behavior. If it sees a pattern that everyday between 11am and 1pm it has bigger changes in location than in the morning or afternoon, your lunch trip would be updated more often. Or with accelerometer support could detect that that is not moving and poll for location less frequently. I'm sure some apps are already doing stuff like this.
I think the problem is much deeper than you'd think. Its very difficult to know the battery cost of an action (some CPU ops take less power iirc), and also I'd imagine that certain execution patterns would be more efficient than others. For example, GPS fixes have some caching involved, so two applications with very similar GPS access patterns could possibly halve their power consumption by simply being scheduled back to back.
Further, I'm not sure whether CPU is really the killer. CPU drain affects latency, which is bad, but for example keeping the radio running (data access), or keeping say accelerometer sensors on (perhaps the generate constant interrupts that interfere with the system's low power state.)
I have an Android phone, and there is some screen that displays uptime statistics and also "time awake" which I think is an indicator for the proportion of the time the CPU is maxed, and even when I run top on my phone I have NO idea what it means or whats at fault. This is partly a tools problem and also partly a problem of some things being products of some particular interleaving.
Another thought is that you have to be very careful about what you measure. Even in the desktop, lots of IO will probably show up as IO waits in your process, so latency is suffering even though the process itself is unrunnable (and worse, the blame would fall on the kernel's IO scheduler probably, thus hiding the blame further. And what if you want to write something but your system is already busy? Who's at fault, the other guys in the IO queue? What if all the apps in the queue are being nice and its just say a DB engine with raw disk access? Complicated complicated stuff.)
Also, my scheme is precisely about user applications not getting all the CPU they need. They'll be absolutely guaranteed to only get the miserly little bit we give them. This will come in the form of a single user background process that runs in totally predictable time slices and -- from the POV of the OS -- never throws an exception. (User background code will throw an exception, but it would be virtual.) Thus, we are guaranteed to never get exception handling overhead from the background apps. Likewise, we are saving context switching overhead by using "green processes". One would be able to achieve a completely paranoid level of sandboxing this way.
The purpose of my post is not to do engineering for Apple. It's to show there's no reason for Apple to not give us background processes!
(One comment on the basic approach: many languages that use green threads don't scale well in multicore due to issues like lock contention or IO wait.)
Preemptive multithreading still leaves the OS with final control (for your "miserly time slice" comment. Which I find very problematic for things like say Loopt where for example you will spend more time waiting for a GPS fix or on network latency than actual computation time...)
How does a "virtual" exception handler become cheaper than any other implementation? It seems the work required is roughly the same (catch dangerous situations, jump to the correct handler).
I suppose there would be lower context switching costs with the use of green threads (skip a user->kernel->user transition), but I suspect it would require programming without any synchronous anything (all IO would have to be asynchronous probably in order for threads to "yield" back to the virtual task scheduler).
(Sorry kind of rambling, I'm pretty much curious about every sentence you wrote ;) I don't think traditional multiproccessing models really pose any control problems that are solved by running a single user thread that does its own scheduling IMO)
Somehow I don't think multicore will be an issue with the iPhone for some time to come. Also, putting all of the user-app background processing on a specially designated processor on a multicore mobile device actually sounds like a good idea.
I'm certainly not an expert in this sort of thing. Again, my point is really -- okay, Apple says that OS X is not safe enough for background processes on a phone, so why don't they try this ultra-paranoid VM?
As for how I'm thinking of this: there is always some small overhead for real context switches and exception handling. If some malicious program decides to be obnoxious, then this can still be felt by the user. If all user applications are creating background processes and Hardin's "Tragedy of the Commons" takes hold, then my experience with all desktop OS I've seen makes me suspect that the user will still feel some small effect. I was trying to come up with a way that you could eliminate even this.
Also, I know for a fact that the virtual exception handler in Smalltalk VMs is a lot cheaper from the POV of the OS. It's just normal execution of the app, as far as the OS and other processes go. I can pop off exceptions like it's going out of fashion and no one else cares. They're like "green exceptions."
Programming without synchronous anything is exactly what I had in mind for background code. The OS gets all the advantages. The VM is just the ultra-paranoid option to make sure that there are no unpredictable battery-life or security downsides. (There can still be parts of the API that look synchronous to the background user app code.) The foreground part will need to get the results off of some sort of lightweight message passing mechanism.
Instead, they should just turn on GPS once every five or ten minutes, especially if I'm not moving.