Adaptation/GUID-F75F975B-A490-4EB5-96CD-B2F8DFC63C7C.dita
changeset 15 307f4279f433
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-F75F975B-A490-4EB5-96CD-B2F8DFC63C7C.dita	Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,35 @@
+<?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-F75F975B-A490-4EB5-96CD-B2F8DFC63C7C" xml:lang="en"><title>Asynchronous
+Requests</title><shortdesc>This document describes how device drivers use asynchronous requests.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-834B2C34-5C8B-4D6D-85F3-FADD357AD330">             <p>An
+asynchronous request is one which is used, typically, to communicate with
+the hardware itself. The time taken for such a request to complete depends
+on the hardware, and the client user-side thread may want to continue with
+some other processing.  The user-side thread is not blocked and can continue
+with other operations, including issuing other requests (synchronous or asynchronous).</p> <p>An
+asynchronous request is started by a call to <xref href="GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066.dita#GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066/GUID-FCC4A3A9-69F5-3947-8D0F-2AD12086F1E2"><apiname>RBusLogicalChannel::DoRequest()</apiname></xref>.
+Control normally returns as soon as the request has been issued, successfully
+or otherwise. Typically, the hardware indicates completion of an operation
+by generating an interrupt. This is handled by an Interrupt Service Routine
+(ISR) provided by the driver. This, in turn, schedules a DFC, which at some
+later time, runs in the context of a kernel-side thread, and signals the client-user
+side thread, marking the asynchronous request as complete. </p> <p>More than
+one asynchronous request can be outstanding at the same time, each one associated
+with its own <xref href="GUID-E0B34F3E-D4C4-3232-B8B1-7DB35B454646.dita"><apiname>TRequestStatus</apiname></xref> object and each identified
+by a specific request number. The device driver framework puts no explicit
+limit on the number of concurrent outstanding asynchronous requests; any limit
+must be enforced by the driver itself. However, the API to cancel a request
+implicitly prevents you from uniquely identifying more than 32 concurrent
+requests. </p> <p>An outstanding asynchronous request can be cancelled by
+a call to <xref href="GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066.dita#GUID-6FBFA078-8253-3E24-B1F8-5F75E86C3066/GUID-16E139F5-4473-33C0-BCDD-A92152D4E8E6"><apiname>RBusLogicalChannel::DoCancel()</apiname></xref>. </p>     </section>
+</conbody></concept>
\ No newline at end of file