Chapter 1

You have to face some key issues here – issues that don't trouble modern desktop software
developers:
� You have to program efficiently so that your programs don't use RAM unnecessarily.
We've already begun to see how descriptors help with that.
� You have to release resources as soon as possible because you can't afford a running
program to gobble up more and more RAM without ever releasing it.
� You have to cope with out-of-memory errors. In fact, you have to cope with potential
out of memory in every single operation that can allocate memory because an out-ofmemory
condition can arise in any such operation.
� When an out-of-memory situation arises that stops some operation from happening,
you must not lose any user data, but must roll back to an acceptable and consistent
state.
� When an out-of-memory situation occurs partway through an operation that involves
the allocation of several resources, you must clean up all those resources as part of the
process of rolling back.
Important These considerations are fundamental to a successful handheld
system. An operating system for mobile phones that doesn't
provide the programmer with good support in these areas is
doomed.
Here are some examples of where you might run out of memory when using a real mobile
phone.
When you launch a new application, resources are created first by the kernel (memory to
hold information about the new process and thread used by the application), then by the
application itself (the memory it requires), and then by various servers throughout the
system. (The file server is constantly at the ready to load application resources, and the
window server displays the application's graphics on-screen, and queues keyboard and
pointer events to the application when it has focus.) At any time during this sequence, the
attempt to allocate one of these resources may fail because of an out-of-memory condition.
The whole application launch has to be called off, and the application, the kernel, and any
servers that allocated resources during the aborted launch must then release them.
Application launch requires a lot of resources, so it's a good guess that the whole operation
might fail if the system is running out of them. However, each of the resources required by
the application is allocated individually, and potential failure must be detected in each
possible case. Proper cleanup must occur wherever the failure occurred.
It's easy enough to clean up on application launch – you just kill everything and the
application isn't launched. Nobody's data gets lost and the user understands what has
happened.
Other examples are more demanding. Imagine that you're typing into a word processor
document. Each key you press potentially expands the buffers used to store and format the
rich text object that's at the heart of the word processor application. If you press a key that
requires the buffers to expand, but there is insufficient memory available, the operation will
fail. In this case, it would clearly be quite wrong for the application to terminate – all your
typing would be lost. Instead, the document must roll back to the state it was in before the
key was processed, and any memory that was allocated successfully during the partially
performed operation must be freed.
In fact, the Symbian OS error handling and cleanup framework is good for more than OOM
errors. Many operations can fail because of other environment conditions – reading and
writing to files, opening files, sending and receiving over communications sessions. The
error handling and cleanup framework can make it easier to deal with those kinds of errors
too.