Editing Documentation/Maemo 5 Developer Guide/DBus/D-Bus Server Design Issues (section)

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

Learn more about Contributing to the wiki.

== Event Loops and Power Consumption ==

Most modern CPUs (even for desktops and servers) allow multiple levels of power savings to be selected. Each of the levels is progressively more power-conservative, but there is always a price involved. The deeper the power saving level required, the more time it normally takes to achieve it, and the more time it also takes to come out of it. In some CPUs, it also requires special sequences of instructions to run, hence taking extra power itself.

All this means that changing the power state of the CPU should be avoided whenever possible. Obviously, this is in contrast to the requirement to conserve battery life, so in effect, what is needed is to require the attention of the CPU as rarely as possible.

One way at looking the problem field is contrasting event-based and polling-based programming. Code that continuously checks for some status and only occasionally performs useful work is clearly keeping the CPU from powering down properly. This model should be avoided at all cost, or at least its use should be restricted to a bare minimum, if no other solution is possible.

In contrast, event-based programming is usually based on the execution of callback functions when something happens, without requiring a separate polling loop. This then leaves the question of how to trigger the callbacks, so that they are issued when something happens. Using timer callbacks can seem like a simple solution, so that it continuously (once per second or more often) checks for status, and then possibly reacts to the change in status. This model is undesirable as well, because the CPU is not able to enter into deep sleep modes, but fluctuate between full power and high-power states.

Most operating system kernels provide a mechanism (or multiple mechanisms) by which a process can be woken up when data is available and otherwise kept off the running queue of the scheduler. The most common mechanism in Linux is based around the <code>select</code>/<code>poll</code> system calls, which are useful when waiting for a change in status for a set of file descriptors. Because most of the interesting things in Linux can be represented as a "file" (an object supporting read and write system calls), using select and poll is quite common. However, when writing software that uses GLib (implicitly like in GTK+ or explicitly like in the non-GUI examples in this document), the <code>GMainLoop</code> structure is used instead. Internally, it uses the event mechanism available on the platform (<code>select</code>/<code>poll</code>/others), but the program needs to register callbacks, start the main loop execution and then just execute the callbacks as they come.

If there are some file descriptors (network sockets, open files, etc), they can be integrated into the <code>GMainLoop</code> using <code>GIOChannel</code>s (see the GLib API reference on this).

This still leaves the question of using timers and callbacks that are triggered by timers. They should be avoided when:

* The timer is used at high frequencies (greater than 1 Hz) for long periods of time (greater than 5 seconds).
* There is a mechanism that triggers a callback when something happens, instead of forcing a manual status poll or re-executing a timer callback that does the checking.

As an example, the LibOSSO program (FlashLight) has to use timers in order to keep the backlight active. However, the timer is very slow (only once every 45 seconds), so this is not a big issue. Also, in FlashLight's defense, the backlight is on all the time, so having a slow timer does not hurt battery life very much anyway.

Another example could be a long-lasting download operation, which proceeds slowly but steadily. It is advisable to consider whether updating a progress bar after each small bit of data is received makes sense (normally it does not). Instead, it is better to keep track of when was the last time when the progress bar was updated, and if enough time has passed since the last time, update the GUI. In some cases, this allows the CPU to be left in a somewhat lower power state than full-power, and allows it to fall back to sleep more quickly.

Having multiple separate programs running, each having their own timers, presents another interesting problem. Because the timer callback is not precise, at some time the system wakes at a very high frequency, handling each timer separately (the frequency and the number of timers executing in the system is something that cannot be controlled from a single program, but instead is a system-wide issue).

If planning a GUI program, it is fairly easy to avoid contributing to this problem, because it is possible to get a callback from LibOSSO, which tells when the program is "on top" and when it is not visible. When not visible, the GUI does not need to be updated, especially with timer-based progress indicators and such.

Because servers do not have a GUI (and their visibility is not controlled by the window manager), such mechanism does not exist. One possible solution in this case is avoiding the use of timers (or any resources for that matter) when the server does not have any active clients. Resources should only be used when there is a client connection or when there is a need to actually do something. As soon as it becomes likely that the server is not used again, the resources should be released (timer callbacks removed, etc.).

If possible, try and utilize the D-Bus signals available on the system bus (or even the hardware state structure via LibOSSO) to throttle down activity based on the conditions in the environment. Even if making a non-GUI server, the system shutdown signals should be listened to because they tell the process to shutdown gracefully.

All in all, designing for a dynamic low-powered environment is not always simple. Four simple but important rules hold true for most cases:

* Avoid doing extra work when possible.
* Do it as fast as possible (while trying to minimize resource usage).
* Do it as rarely as possible.
* Keep only those resources allocated that you need to get the work done.

For GUI programs, the "graphical side" of things has to be taken into account as well. Making a GUI that is very conservative in its power usage is, most of the time, very simple, but it provides little excitement to the user and can even look quite ugly. The priorities for the programmer can lie in a different direction.

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/DBus/D-Bus_Server_Design_Issues"

Personal tools

Navigation

Views

Editing Documentation/Maemo 5 Developer Guide/DBus/D-Bus Server Design Issues (section)