Chapter 1

The message for a synchronous function must be completed synchronously by the server's
handler function.
We saw in the previous chapter that any asynchronous request must be completed precisely
once – whatever the circumstances. The kernel guarantees that even if the server thread
dies an asynchronous request by a client is completed as part of the kernel's thread-death
cleanup.
We also saw that any API that provides asynchronous request functions should also offer
corresponding cancel functions: so cancel functions too, are often present in servers' client
APIs.
18.1.5 Ending a Session and Cleanup after Client Death
When a client has finished with a client-server session, it should end it with
RSessionBase::Close(). This sends a disconnect message to the server, which
responds by simply destroying its end of the session: by calling the destructor of the
CSharableSession-derived object. Then, the kernel destroys its representation of the
session. The handle of the client-side RSessionBase is set to zero.
It is safe for a client to call Close() on the RSessionBase again: when the handle is zero,
Close() does nothing.
If the client thread dies, the kernel will perform thread-death cleanup and send a disconnect
message to the server end of all the sessions for which it was a client thread. Thus, the
server-side end of the session is destroyed, even if the client thread dies.
Servers must perform effective cleanup. When a CSession/CSharableSession object is
destroyed, any resources associated with it should also be destroyed. Usually, this is just
standard C++ destructor processing.
18.1.6 Cleanup after Server Death
Servers should be written with the greatest care, so they do not terminate prematurely. But if
a server does die, then the kernel gives the opportunity for clients to recover. Any
outstanding messages from asynchronous requests will be completed with the KErrDied
return code.
After a server has died, the client should clean up all RSession-Base objects relating to
that server. Any SendReceive() issued on an RSessionBase to a dead server will result
in a completion code of KErrServerTerminated. This will be the case even if a new
instance of the server is started: old sessions will not be reconnected.
18.1.7 Handling Multiple Objects from One Session
Sometimes it is useful for a single client-side thread to have multiple sessions with a given
server. A good example of this is the socket server; each socket created by the client could
be a separate session. However, creating a new session consumes resources in the server
and in the kernel to support it. Therefore, creating many sessions for one client thread may
be inefficient. An alternative approach is provided by the use of subsessions (see Figure
18.4). In general, if your client thread needs multiple sessions, try to use subsessions.