<?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>