A standard OS mini-daemon, saving power and memory

On every system we use today (except the iPhone) a lot of programs want to be daemons -- background tasks that sit around to wait for events or perform certain regular operations. On Windows it seems things are the worst, which is why I wrote before about how Windows needs a master daemon. A master daemon is a single background process that uses a scripting language to perform most of the daemon functions that other programs are asking for. A master daemon will wait for events and fire off more full-fledged processes when they happen. Scripts would allow detection of connection on ports, updated software versions becoming available, input from the user and anything else that becomes popular.

(Unix always had a simple master daemon for internet port connections, called inetd, but today Linux systems tend to be full of always-running deamons.)

Background tasks make a system slow to start up, and take memory. This is becoming most noticed on our new, lower powered devices like smartphones. So much so that Apple made the dramatic decision to not allow applications to run in the background. No multitasking is allowed. This seriously restricts what the iPhone can do, but Apple feels the increase in performance is worth it. It is certainly true that on Windows Mobile (which actually made it hard to terminate a program once you started it running) very quickly bloats down and becomes unusable.

Background tasks are also sucking battery life on phones. On my phone it's easy to leave Google maps running in the background by mistake, and then it will sit there constantly sucking down maps, using the network and quickly draining the battery. I have not tried all phones, but Windows Mobile on my HTC is a complete idiot about battery management. Once you start up the network connection you seem to have to manually take it down, and if you don't you can forget about your battery life. Often is the time you'll pull the phone out to find it warm and draining. I don't know if the other multitasking phones, like the Android, Pre and others have this trouble.

The iPhone's answer is too draconian. I think the answer lies in a good master daemon, where programs can provide scripts in a special language to get the program invoked on various events. Whatever is popular should be quickly added to the daemon if it's not too large. (The daemon itself can be modular so it only keeps in ram what it really needs.)

In particular, the scripts should say how important quick response time is, and whether the woken code will want to use the network. Consider an e-mail program that wants to check for new e-mail every 10 minutes. (Ideally it should have IMAP push but that's another story.)

The master daemon scheduler should realize the mail program doesn't have to connect exactly every 10 minutes, though that is what a background task would do. It doesn't mind if it's off by even a few minutes. So if there are multiple programs that want to wake up and do something every so often, they can be scheduled to only be loaded one or two at a time, to conserve memory and CPU. So the e-mail program might wait a few minutes for something else to complete. In addition, since the e-Mail program wants to use the network, groups of programs that want to use the network could be executed in order (or even, if appropriate, at the same time) so that the phone ends up setting up a network connection (on session based networks) and doing all the network daemons, and then closing it down.

The master daemon could also centralize event notifications coming from the outside. Programs that want to be woken up for such events (such as incoming emails or IMs) could register to be woken up on various events on ports. If the wireless network doesn't support that it might allow notifications to come in via SMS that a new task awaits. When this special SMS comes in, the network connection would be brought up, and the signalled task would run, along with other tasks that want to do a quick check of the network. As much of this logic should be in the daemon script, so that the full program is only woken up if that is truly needed.

The daemon would of course handle all local events (key presses, screen touches) and also events from other sensors, like the GPS (wake me up if we get near hear, or more than 100 meters from there, etc.) It would also detect gestures with the accelerometer. If the user shakes the phone or flips it in a certain way, a program might want to be woken up.

And of course, it should be tied to the existing daemon that handles incoming calls and SMSs. Apps should be able to (if given permission) take control of incoming communications, to improve what the regular phone does.

This system could give the illusion of a full multitasking phone without the weight of it. Yes, loading in an app upon an event might be slightly slower than having it sitting there in ram. But if there is spare ram, it would of course be cached there anyway. An ideal app would let itself be woken up in stages, with a small piece of code loading quickly to give instant UI response, and the real meat loading more slowly if need be.

While our devices are going to get faster, this is not a problem which will entirely go away. The limiting factors in a portable device are mostly based on power, including the power to keep the network radios on. And applications will keep getting bigger the faster our CPUs get and the bigger our memories get. So this approach may have more lifetime than you think.


Apple is doing this to a limited extent for network messages with it's new notification system. While this covers a lot of apps, it doesn't enable a Google latitude-type app, which is what I'm interested in. There are low-power ways to do this - e.g. only allowing apps to register for low-precision location changes like switching cellphone tower or new wifi beacons appearing. Also, modern GPS chips theoretically allow a very brief wakeup period to register location and then go back to sleep since they can remember the satellite locations from last time (the SiRFstar III chipset has this capability), meaning that they don't need to be amplifying the radio signal and the decoding the whole time.

The way that they implemented the inotify-type functionality in OS X would be a good way of dealing with location-wakeup as well. They could log all of the location data that they're collecting to a file and let apps process events from the file on wakeup.

Adding time-based notifications would cover a lot of the remaining cases.

I applaud Apple for not following the crowd on this issue and I think it'll lead to a better system in the end, but it sure is frustrating in the meantime :)

It's a start, but sometimes you really do need to have background tasks. Apple felt that too many programs would abuse the ability to be a background task (and this is true) and their answer was to have none but what they wrote. I hope that an answer lies in making applications think harder about it, making users think harder about what apps they will bless with that ability. I'm sure we've heard the story of "there's a great app I would like to make for the iPhone, but..." enough.

Particularly annoying, I think, on almost all phones, is the inability to make apps that enhance phone calls. On the iPhone, your app can find out about an incoming call, but once the user answers, you're killed, as I understand it.

One key would be to have a very responsive team managing the master daemon and its events. When a developer says, "I really need a wakeup if the user moves more than a mile, doing this through cell towers is fine" it would be good if the master daemon could quickly be updated to do that.

An OS that is ruthless about handing out CPU and memory would also be nice. Instead of telling people "you can't be in the background" saying "If you want to be in the background, you have to shrink to X kilobytes and no more than Y% of the CPU and I/O. And the user has to enable you to interrupt the app that has focus." Shrinking to a small size in kilobytes is easy in something like a JVM environment as found on Android. You could just say, "When I am in the background, only these classes can operate, any accidental reference outside is an exception."

Isn't this basically launchd on Mac OS X? If Larry Siracusa at Ars Technica is to be believed it's Apple's generalization of inetd. I know it is relatively new, but I gather it was added to the OS around the time of the iPhone release. I think Apple's reservation about background processes, even within a launchd framework, is that two-fold. First there is the matter of the API. What events should it detect? Some are obvious, messages, times, but what about locations or a specific gesture? Second, there is still the matter of resource usage in that they already have a real time intensive set of tasks running the user interface and general communications, and, since this is a primary selling point of the iPhone, they don't want a popular application destroying their painfully created experience.

Add new comment