Adaptation/GUID-F75F975B-A490-4EB5-96CD-B2F8DFC63C7C.dita
changeset 15 307f4279f433
equal deleted inserted replaced
14:578be2adaf3e 15:307f4279f433
       
     1 <?xml version="1.0" encoding="utf-8"?>
       
     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
       
     3 <!-- This component and the accompanying materials are made available under the terms of the License 
       
     4 "Eclipse Public License v1.0" which accompanies this distribution, 
       
     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
       
     6 <!-- Initial Contributors:
       
     7     Nokia Corporation - initial contribution.
       
     8 Contributors: 
       
     9 -->
       
    10 <!DOCTYPE concept
       
    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
       
    12 <concept id="GUID-F75F975B-A490-4EB5-96CD-B2F8DFC63C7C" xml:lang="en"><title>Asynchronous
       
    13 Requests</title><shortdesc>This document describes how device drivers use asynchronous requests.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    14 <section id="GUID-834B2C34-5C8B-4D6D-85F3-FADD357AD330">             <p>An
       
    15 asynchronous request is one which is used, typically, to communicate with
       
    16 the hardware itself. The time taken for such a request to complete depends
       
    17 on the hardware, and the client user-side thread may want to continue with
       
    18 some other processing.  The user-side thread is not blocked and can continue
       
    19 with other operations, including issuing other requests (synchronous or asynchronous).</p> <p>An
       
    20 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>.
       
    21 Control normally returns as soon as the request has been issued, successfully
       
    22 or otherwise. Typically, the hardware indicates completion of an operation
       
    23 by generating an interrupt. This is handled by an Interrupt Service Routine
       
    24 (ISR) provided by the driver. This, in turn, schedules a DFC, which at some
       
    25 later time, runs in the context of a kernel-side thread, and signals the client-user
       
    26 side thread, marking the asynchronous request as complete. </p> <p>More than
       
    27 one asynchronous request can be outstanding at the same time, each one associated
       
    28 with its own <xref href="GUID-E0B34F3E-D4C4-3232-B8B1-7DB35B454646.dita"><apiname>TRequestStatus</apiname></xref> object and each identified
       
    29 by a specific request number. The device driver framework puts no explicit
       
    30 limit on the number of concurrent outstanding asynchronous requests; any limit
       
    31 must be enforced by the driver itself. However, the API to cancel a request
       
    32 implicitly prevents you from uniquely identifying more than 32 concurrent
       
    33 requests. </p> <p>An outstanding asynchronous request can be cancelled by
       
    34 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>
       
    35 </conbody></concept>