Collapse all Symbian^3 Product Developer Library

Sharable sessions

Describes how a session can be shared by threads.

A session can be shared by threads provided the server is marked as supporting shared sessions.

Sharing

Once a server has started, and a client has connected to that server (by creating a session), then the client thread can make the session sharable. There are two types of sharing:

where the session is sharable among all threads belonging to the same process as the originating thread.
where the session is sharable among all threads in the system, i.e. across all processes.

A server must support the creation of sharable sessions, otherwise an attempt to make a session sharable panics the calling thread. Servers can be created to be either unsharable, sharable among threads in the same process, or sharable among all threads in the system.

Sharing a session among threads in a single process

There are two ways of doing this:

if the session has already been created, then call RSessionBase::ShareAuto(), which has the effect of mutating the handle from a thread relative handle to a process relative handle. The handle can then be shared by the threads. Until this function is called, the session is specific to the originating thread, and cannot be used by any other thread.
if the session has not yet been created, then create the session as sharable from the beginning using one of the overloads of RSessionBase::CreateSession() that takes a TIpcSessionType argument - this is the preferred method

Sharing a session among threads across all processes

There are two ways of doing this:

if the session has already been created, then call RSessionBase::ShareProtected(), which has the effect of mutating the handle from a thread relative handle to a process relative handle; this is also protected and can be passed to another process. The handle can then be shared by the threads. Until this function is called, the session is specific to the originating thread, and cannot be used by any other thread.
if the session has not yet been created, then create the session as sharable from the beginning using one of the overloads of RSessionBase::CreateSession() that takes a TIpcSessionType argument - this is the preferred method

Server exit

If the server terminates, all outstanding messages which have been sent to it are completed with a KErrServerTerminated code. Any attempt to send further messages, or to share session, fail immediately with KErrServerTerminated. The only valid operation on such a session is to close it.

Session closure

If Close() is called on a session, any outstanding messages on the session may not be completed for the client. Following this, the only message that the server receives from the session is the disconnect message.

Client thread exit

If a session has not been shared, then the session is closed as part of normal thread cleanup.

If a session has been shared, the session handle is owned by the process and is not automatically cleaned up with the thread. In addition, the server is not informed that the thread has terminated.

The only way to free resources owned by the session is to explicitly close the session, or to terminate the client process. Note that this makes it possible for a session to have no client threads !

Message slots

The maximum number of message slots that can be allocated to a session, or the maximum number that can be dynamically acquired from the system-wide pool, is 255.

Parent topic: Using Client-Server