<?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-3A4947BD-1BEB-521C-BEDF-738064E83FE6" xml:lang="en"><title>Cancelling

an asynchronous request</title><shortdesc>This document describes how to cancel an asynchronous request.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Most asynchronous service providers support a cancel function. This allows

an outstanding request to be cancelled before it is complete. </p>

<p>A single thread that is waiting for a single asynchronous request to complete

cannot cancel that request because the thread is asleep until it completes.

However, when multiple requests are outstanding, the handling of a request

completion may involve cancelling some or all of the other outstanding requests.</p>

<p>In all cases, the correct user protocol for cancellation is:</p>

<codeblock id="GUID-849238B9-205F-56ED-8958-B28F7604108C" xml:space="preserve">    // only cancel if we know that there is

    // an outstanding request

if (requestIssued)

    {

        // Issue cancel to service provider

    provider.cancel();

        // Wait for it complete (it must complete)

    User::WaitForRequest(requestStatus);

        // Now note that request is no longer outstanding

    requestIssued=EFalse;

    }</codeblock>

<section id="GUID-13C429B3-7FEF-4A2E-991C-767908F0AA5E"><title>Notes</title> <ul>

<li id="GUID-A905DF5E-2AAA-59F8-B817-D10FBD947B9A"><p>A cancel should only

be issued from the thread that issued the request.</p> </li>

<li id="GUID-F4500BC1-6FDF-5D7D-8E62-641246AAE051"><p>It is convention that

cancel functions provided by asynchronous service providers have <codeph>Cancel</codeph> somewhere

in the name, but need not necessarily be called <codeph>Cancel()</codeph>.</p> </li>

<li id="GUID-8383581F-B687-5BBE-8F7E-71EC4360A7E0"><p>An asynchronous service

provider must make certain guarantees about cancellation:</p> <ul>

<li id="GUID-0383D830-FB83-5707-9FE3-60360ACA9395"><p>it must complete quickly —

otherwise, the <codeph>User::WaitForRequest()</codeph> above would take a

long time to complete, and cause the program to become unresponsive</p> </li>

<li id="GUID-0266E0CB-DC3B-597F-8662-B9AA4AAF35C3"><p>it must not violate

the guarantee that each request produces precisely one signal</p> </li>

</ul> </li>

<li id="GUID-C7C67368-C52D-5830-98FC-DA0AD31917DC"><p>The service provider

does not have to guarantee to cancel the actual request: it may already have

completed — asynchronously, by definition — by the time the client

thread issues the cancel.</p> </li>

<li id="GUID-2290B823-B990-5A35-87DB-4BEC312C440E"><p>Although the cancel

must return quickly, the service initiated by the request may not have completed.

For instance, if data were requested from a network drive, it may not be returned

until after the cancel. Because of the cancel, the service provider must discard

such data.</p> </li>

</ul> </section>

</conbody></concept>