Chapter 1

� Request the window server to draw the bitmap
� Delete the bitmap.
By the time the client's buffer is flushed and executed by the window server (the third step
above), the bitmap could have been deleted. To avoid this, the FBS client-side
implementation calls the window server client's Flush() function (through an interface
function) before sending the FBS message to delete the bitmap.
Note
As well as handling ROM- and RAM-resident bitmaps, the FBS also handles
ROM- and RAM-resident fonts. The precise details are different from those
for bitmaps, but the motivations for using a server to share font data are
essentially the same.
The shared memory technique is not without cost:
� The shared heap is mapped to different addresses in different processes. This means
that conventional pointers cannot be used within the heap: a handle system has to be
used instead.
� The shared heap is not the default heap for either client or server process. This means
that the default operator new() and operator delete() don't work.
� For both the above reasons, objects designed for use in the default user heap cannot
be placed onto a shared heap. New classes must be written specially for this purpose.
� You have to use mutex synchronization to control access to objects on the shared
heap.
� You have to make sure that things stay in sync when you delete objects that are
shared with other servers.
For the font and bitmap server, these costs are low because the shared heap contains largescale
objects (fonts and bitmaps) and because the usage patterns of these objects minimize
the difficulties of mutex-based sharing. In addition, the benefits of sharing are very high
because of:
� the intensity of operations involving bit-blitting,
� the enormous difference the efficient implementation makes to users' perceptions of
system efficiency
� the size of the objects that would have to be exchanged using client-server
transactions if the shared heap was not available.
Other shared-heap server designs have been implemented on Symbian OS, but in each
case the design issues and the cost/benefit analysis have had to be thought through very
carefully.
18.3 Servers and Threads
The session between a client and a server is owned by the kernel. The kernel specifies that
the session is between the client thread or process and the server thread. This has simple,
but profound implications for any program that uses servers:
� Unless sharable sessions are used, client-side resources representing server-side
objects may only be used and destroyed by the client thread that created them.
� Server responsiveness to clients is governed by the duration of the longest possible
RunL() of any active object running on the server thread.
Most of the time, these implications are not onerous. Most Symbian OS clients and servers
are single-threaded, and the active object paradigm for event-handling threads is perfectly
adequate. In a few cases, though, these implications raise issues for Symbian OS
programmers and, as usual, some techniques have been developed to tackle them.