Chapter 1

A good example of this is the capability and setup pattern used by the serial communications
and other Symbian OS servers. Rather than providing many getter/setter functions to test
and change the state of a communications port – speed, parity, data bits, stop bits,
XON/XOFF, and the like – the communications server provides a single struct containing
all the settings. You use a Config() call to get this struct; you can then change values
in it, and use SetConfig() to send it back to the communications server.
18.2.3 Data Caching
Rather than read a data value from a server every time you need it, it's sometimes a good
idea to cache the data value client side. When they need it, your client programs can use
this value without a client-server transaction. However, you must ensure that the cached
value is updated when necessary.
For example, the Battleships status display shows the GDP protocol in use for the
communication session. You can get this protocol from the GSDP server using a simple
client API call, but that would require a client-server transaction every time the status view is
drawn. It seemed simpler to cache the value in the status view and to update it whenever the
client changes the settings.
If the setting is updated by the server outside the client's control, then you need to use
another method to update the client-side cache. For example, the system shell displays files
in the current folder and highlights any files that are currently open. Files may be deleted and
programs opened and closed, outside the shell's control. To keep the display up to date, the
shell uses notification APIs in both the file server (which knows about all files) and the
window server (which knows about all open GUI applications). The notification API
generates an event when a relevant change occurs. The shell then responds to this event by
asking the server for updated information. Thus, there is no need for the shell to poll (which
would waste power and time), or to require the user to refresh the display (which would be
confusing).
Note
On the emulator, you can alter a file visible to the shell by using the Windows
shell rather than that of Symbian OS. If you want Symbian OS to pick up this
change and notify its shell, press and release F5. This simulates opening
and closing the door on a real machine for a removable media device. In
turn, this causes the file server to notify the shell of general changes and the
shell does a complete rescan.
18.2.4 Related Servers in the Same Process
Two key aspects of a client-server transaction are cheaper if the client and server are on
different threads in the same process:
� Context switching is much cheaper, because no changes to the MMU are required.
� Interthread data transfer is cheaper, because there is no need to map the relevant
client's data space into the server's address space.
These effects are particularly relevant in the hardware implementations used by most current
available Symbian OS phones. Like the Psion Series 5, they use a postcache MMU in order
to save power. This means that the entire cache has to be flushed after a context switch,
which slows things down.
There are several ways to ensure that a client-server call avoids these overheads.