Asynchronous -Services Overview

Purpose

Provides low-level and high-level idioms -by which one thread or process in Symbian platform can request services from -another.

Client programs typically use these idioms when accessing -system services such as windowing, or telephony. This process is so fundamental -that the basic structure of nearly all Symbian platform applications is based -on its encapsulation in the active object framework.

Architectural relationships

Asynchronous services -are used throughout Symbian platform, most commonly as encapsulated in the -client/server architecture. Some APIs may in turn wrap client/server relationships -in framework classes, so that it is not immediately obvious that a client -program is using asynchronous services. The most important case of this is -the UI application framework, which wraps client requests to be informed of -user interface events.

Description

General -properties

Client programs must often request access to services -provided by other threads or processes. For example, most application programs -will request the system's window server process to inform it of keyboard input. -A thread or process that provides such services is called an asynchronous -service provider.

When a function call to an asynchronous service -provider returns, it means only that the request has been despatched. The -asynchronous service provider informs the requester that it has actually completed -the request through a signalling mechanism.

Low-level asynchronous -service handling shows the basic asynchronous services concepts.
High-level asynchronous -service handling shows the Symbian platform framework that encapsulates asynchronous -service handling.

Low-level -asynchronous service handling

Low-level asynchronous service handling -has two key concepts, asynchronous request status, and thread request semaphore.

Asynchronous request status

An asynchronous request status -indicates the completion status of a request to a service provider. When a -thread makes a request, it passes an asynchronous request status as a parameter. -When the provider completes the request, it stores a success or error code -in the request status.

The asynchronous request status is provided -by TRequestStatus.

Thread -request semaphore

A thread request semaphore is the means by which -a provider signals a requester that it has completed a request. Client code -can then determine which request has completed, and call an appropriate function -to handle completion of the request.

Functions to signal a thread -request semaphore, and to wait until it has been signalled are provided by -the System Static Functions API User class.

High-level asynchronous service handling

High-level asynchronous -service handling has two key concepts, active object, and active scheduler.

Active object

An active object encapsulates the general behavior -of making requests to asynchronous service provider, and handling the completion -of requests. Particular asynchronous service provider typically supply active -object based classes as interfaces by which clients to access them.

The -active object interface is provided by CActive.

Active scheduler

A thread which uses asynchronous services -must have a main loop that waits on the thread’s request semaphore for any -outstanding requests to complete. The active scheduler encapsulates this wait -loop. An active scheduler is provided for all GUI programs. A high-level view -of a GUI application is therefore is that it is a set of active objects to -handle request completion events fed it by its active scheduler.

The -active scheduler interface is provided by CActiveScheduler.