Asynchronous Services Overview

Provides low-level and high-level idioms by which one thread or process in EPOC 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 EPOC applications is based on its encapsulation in the active object framework.

Asynchronous services are used throughout EPOC, 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.

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 EPOC framework that encapsulates 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 has two key concepts, active object, and active scheduler.

Active object

An active object encapsulates the general behaviour 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.

Client/Server Overview

Semaphores Overview

System Static Functions Overview

Uikon Core Overview