Chapter 1

The process of switching execution between one thread and another is context switching.
Like any other system, Symbian OS's scheduler is written carefully to minimize the
overheads involved in context switching.
Nevertheless, context switching is much more expensive than, say, a function call. The most
expensive type of context switch is between a thread in one process and a thread in another
because a process switch also involves many changes to the MMU settings, and various
hardware caches must be flushed. It's much cheaper to context switch between two threads
in the same process.
Typically, each Symbian OS application uses its own process that consists of just one main
thread. Each server also uses its own process and just one thread. The decision to use a
separate process for each application and server is one of security – a process cannot
deliberately or accidentally change another process' memory. In cases where servers are
designed to cooperate closely together, they are sometimes packaged into a single process
so that context switching between them is cheaper. Thus, all the major communicationsrelated
servers in Symbian OS – serial, sockets, and telephony – run in the same process.
How can an application or server run effectively in a single thread? Don't sophisticated
applications need to perform background tasks? And shouldn't a server have a single thread
for each client? Symbian OS implements sophisticated applications and servers using only a
single thread because it has a good event-handling system based on active objects. I'll
return to that in the Event Handling section below.
2.4 Executable Programs
As far as the CPU is concerned, a C++ program is just a series of instructions. But if we
want to manage software development and deployment effectively, we have to group code in
more convenient packages. The packages Symbian OS uses are closely based on those
used by Windows NT and similar systems. They are as follows:
� a .exe – a program with a single main entry point E32Main(). When the system
launches a new .exe, it first creates a new process. The entry point is then called in the
context of the main thread of that process.
� A dynamic link library or DLL – a library of program code with potentially many entry
points. The system loads a DLL into the context of an existing thread (and therefore an
existing process).
Both these are executables. I'll use 'executable' when I mean either a .exe or a DLL. I'll
never use just 'executable' if I mean a .exe specifically – I'll use '.exe'.
There are two important types of DLL, which are as follows:
� A shared library DLL provides a fixed API that can be used by one or more programs.
Most shared library DLLs have the extension .dll. Executables are marked with the
shared libraries they require and, when the system loads the executable at runtime, the
required shared libraries are loaded automatically. This happens recursively, so any
shared libraries needed by the shared libraries are also loaded, until everything required
by the executable is ready.
� A polymorphic DLL implements an abstract API such as a printer driver, sockets
protocol, or an application. Such DLLs typically use an extension other than .dll – .prn,
.prt, or .app, for instance. In Symbian OS, polymorphic DLLs usually have a single entry
point, which allocates and constructs a derived class of some base class associated
with the DLL. Polymorphic DLLs are usually loaded explicitly by the program that
requires them.
2.4.1 The Place of Execution