3 ms·

Weirdly, Android (and most other operating systems) have the ability to run background processes without anywhere near as complicated a system. They just imple

Weirdly, Android (and most other operating systems) have the ability to run background processes without anywhere near as complicated a system. 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.)

thwarted 18y ago
That's one thing that is often missing, some kind of quick process listing. People would eventually associate their battery life with the list of programs running or installed, and would be able to make more informed choices about which apps to install and/or use. It would also give an incentive to app programmers to not be so aggressive, as their aggressive app will be associated with low battery life or unresponsive UI. 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.
- litewulf 18y ago
  (disclaimer: I've only used a cellphone and never made one.) 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.)
  - stcredzero 18y ago
    Really the point of my "ultra paranoid VM" idea that I brought up in the other thread is that there are ways that Apple could put a strict upper bound on the amount of CPU that user background apps can use. I just said it in far too many words, using less than optimal tools.
    - litewulf 18y ago
      :) cool I understand what you're saying.
stcredzero 18y ago
Yes, there's always ordinary preemptive multi threading. My idea is more of a "proof by example." Even if somehow conventional tools are not enough, there are still ways that Apple can guarantee totally paranoid control, but still give developers background processes. 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!
- litewulf 18y ago
  I really don't understand the advantages of your approach. I'm willing to believe I'm just dumb though ;) (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)
  - stcredzero 18y ago

thwarted 18y ago

That's one thing that is often missing, some kind of quick process listing. People would eventually associate their battery life with the list of programs running or installed, and would be able to make more informed choices about which apps to install and/or use. It would also give an incentive to app programmers to not be so aggressive, as their aggressive app will be associated with low battery life or unresponsive UI. 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.

litewulf 18y ago
(disclaimer: I've only used a cellphone and never made one.) 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.)
- stcredzero 18y ago
  Really the point of my "ultra paranoid VM" idea that I brought up in the other thread is that there are ways that Apple could put a strict upper bound on the amount of CPU that user background apps can use. I just said it in far too many words, using less than optimal tools.
  - litewulf 18y ago
    :) cool I understand what you're saying.

stcredzero 18y ago

Yes, there's always ordinary preemptive multi threading. My idea is more of a "proof by example." Even if somehow conventional tools are not enough, there are still ways that Apple can guarantee totally paranoid control, but still give developers background processes. 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!

litewulf 18y ago
I really don't understand the advantages of your approach. I'm willing to believe I'm just dumb though ;) (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)
- stcredzero 18y ago