diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-1294F540-FDA7-5050-BAFB-3C9888491B98.dita
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-1294F540-FDA7-5050-BAFB-3C9888491B98.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-1294F540-FDA7-5050-BAFB-3C9888491B98" xml:lang="en"><title>Asynchronous
+Services Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-6F9E9225-A8E2-41C9-B7B5-A89E2800445C"><title>Purpose</title> <p>Provides low-level and high-level idioms
+by which one thread or process in Symbian platform can request services from
+another.</p> <p>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.</p> </section>
+<section id="GUID-CA918B24-FFC7-47C1-A683-F8AE01192ED3"><title>Architectural relationships</title> <p>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.</p> </section>
+<section id="GUID-78BD76F0-7785-4238-A17F-40B7117BEB39"><title>Description</title> <p><b>General
+properties</b> </p> <p>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 <i>asynchronous
+service provider</i>.</p> <p>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.</p> <ul>
+<li id="GUID-E6B20563-4114-5896-A80E-1D2195631346"><p>Low-level asynchronous
+service handling shows the basic asynchronous services concepts.</p> </li>
+<li id="GUID-A84879C4-703D-5681-934D-D7649440A67F"><p>High-level asynchronous
+service handling shows the Symbian platform framework that encapsulates asynchronous
+service handling.</p> </li>
+</ul> <p><b>Low-level
+asynchronous service handling</b> </p> <p>Low-level asynchronous service handling
+has two key concepts, asynchronous request status, and thread request semaphore.</p> <p><b>Asynchronous request status</b> </p> <p>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.</p> <p>The asynchronous request status is provided
+by <xref href="GUID-E0B34F3E-D4C4-3232-B8B1-7DB35B454646.dita"><apiname>TRequestStatus</apiname></xref>.</p> <p><b>Thread
+request semaphore</b> </p> <p>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. </p> <p>Functions to signal a thread
+request semaphore, and to wait until it has been signalled are provided by
+the System Static Functions API <xref href="GUID-C197C9A7-EA05-3F24-9854-542E984C612D.dita"><apiname>User</apiname></xref> class.</p> <p><b>High-level asynchronous service handling</b> </p> <p>High-level asynchronous
+service handling has two key concepts, active object, and active scheduler.</p> <p><b>Active object</b> </p> <p>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. </p> <p>The
+active object interface is provided by <xref href="GUID-067293BF-B28C-3CEC-92F4-1351A795EA7F.dita"><apiname>CActive</apiname></xref>.</p> <p><b>Active scheduler</b> </p> <p>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.</p> <p>The
+active scheduler interface is provided by <xref href="GUID-B4C76104-EA1B-3FC3-A31E-86A976598171.dita"><apiname>CActiveScheduler</apiname></xref>.</p> </section>
+<section id="GUID-67C2E21D-8F63-4637-832F-9EBD4B2FF4AF"><title>See also</title> <p><xref href="GUID-D0D27AEA-FDDB-5F6F-94F6-ADDF5910DC47.dita">Client/Server
+Overview</xref> </p> <p><xref href="GUID-E865E677-1219-500C-89CF-0A2835B91834.dita">Semaphores
+Overview</xref> </p> <p><xref href="GUID-FF8F5D97-7D37-5F6B-84A3-C064E2FD53E0.dita">System
+Static Functions Overview</xref> </p> </section>
+</conbody></concept>
\ No newline at end of file