Chapter 1

You can control the stack size in a .exe. This can apply to console programs, servers, or
programs with no GUI – but not to UIQ programs, since they are launched with apprun.exe.
You can also control the stack size when you launch a thread explicitly from within your
program. If you have an application with an algorithm that requires a large stack such as a
heavily recursive game-tree search, you may have to encapsulate the algorithm in a .exe of
its own, or a separate thread.
Since each user heap eats into a scarce system resource – the free page list – and since
applications and servers run for months or years without being restarted, it's vital that
programs detect heap failure due to a lack of memory. It's also vital that programs release
unneeded memory as soon as possible. This is the domain of the Symbian OS cleanup
framework, which is covered in Chapter 6.
Threads have independent default heaps in the sense that each thread always allocates
from its own heap. But since all heaps are in the same process' address space, each thread
in a process can access objects on other heaps in that process – provided suitable
synchronization methods are used.
In addition to the default heap, threads can have other heaps. But these introduce new
complications, so you should use them only if you have to. For any nondefault heap, you
must provide a specific C++ operatornew() to allocate objects onto it. For local shared
heaps–shared with other threads in the same process – you have to introduce
synchronization using mutexes or the like. For global shared heaps – shared with threads in
other processes – the heap is mapped to a different address in each process, so you have to
introduce a smart reference system rather than straightforward pointers. All these things are
possible if necessary – but they're rarely necessary. Usually, it's better to use a server to
manage shared resources, rather than a shared heap. There's an overview of servers below,
and they are covered more thoroughly, including performance optimization, in Chapters 18,
19 and 20.
A thread's nonshared heaps are allocated into a 256 MB region of a process' virtual address
space. By limiting the maximum size to 2 MB, there is an implied maximum of 128 threads
per process.
2.9.2 No Writable Static Data in DLLs
DLLs only support read-only data, and program code. Writable static data is supported only
by .exe is. This imposes some design disciplines on native Symbian OS code. It also
makes life more difficult when porting code, which often assumes the availability of writable
static. A feasible workaround is to use a .exe to contain the ported code. The .exe is
packaged as a Symbian OS server, which allows it to be shared between multiple programs.
By using a separate process, we also gain the benefit of isolation.
Porting code would be much simpler if writable static data were supported, but then each
DLL that uses this feature would contain fixed references to the address of its data. Every
process using the DLL would therefore have to place the data at this specified address. In an
open programming environment such as Symbian OS, you would need some form of
system-wide DLL memory allocator to ensure that there are no clashes between the address
requirements of different DLLs, and that an appropriate address will be available in every
process that might use any given DLL. Symbian considered implementing such a system,
but decided that it would impose unacceptable penalties on code size, execution times and
RAM usage.
Conventional operating systems circumvent the issue by detecting when the required
address is not free in any particular process, making a copy of the DLL and modifying the