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