<?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-E651C7A7-D6EB-533E-A97A-360D089DE7A5" xml:lang="en"><title>Inter-thread

data transfer</title><shortdesc>Describes how data is transferred between threads.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>The client-server message protocol supports the passing of a 32-bit request

code and four 32-bit parameters from client to server and returning a 32-bit

result from the server to the client. The parameters may be interpreted as

plain integers or pointers; pointer types may be untyped (<codeph>TAny*</codeph>)

or descriptor types (<codeph>TDesC8*</codeph> and <codeph>TDesC16*</codeph>)

that the server can use to access the client’s address space. The request

code, parameters, and the parameter types are packaged into a <xref href="GUID-4AD02F14-1142-372F-9D11-224595932034.dita"><apiname>TIpcArgs</apiname></xref> object.

The parameter types are stored in the kernel side message object so that the

kernel can check that subsequent operations requested by the server using

the message are: </p>

<ul>

<li id="GUID-1F925301-81D0-5F84-ABEE-BB4DB576DBC1"><p>correct; for example,

checking that the source and target descriptors are either both 8-bit or both

16-bit descriptors </p> </li>

<li id="GUID-EE7CCC5F-0013-55EA-B473-763785F5CD90"><p>permitted by the client;

for example, checking that when the server tries to write to a client descriptor,

that the client descriptor is <xref href="GUID-49D4E917-57EA-39AE-8941-144AA8AC2584.dita"><apiname>TDes</apiname></xref> -derived (modifiable),

rather than <xref href="GUID-52D07F46-2162-380C-A775-C3BB335C42F5.dita"><apiname>TDesC</apiname></xref> -derived (non-modifiable) </p> </li>

</ul>

<p><note>NOTE:</note> although you can pass untyped pointers, it is not possible

to directly access memory in another thread’s address space using an arbitrary

pointer as this is inherently insecure. The ability to pass a pointer between

a client and server is therefore only of value when the client and server

are within the same process. In this case, the use of a pointer is obviously

not limited to pointing to a descriptor, but may also be used to point to

an arbitrary data structure containing information to be shared between the

client and server. </p>

<p>It is important to note that a server may not run until some arbitrary

time after a client issues a request. Any descriptor containing data to be

passed to the server must be guaranteed to exist until the request completes.

For this reason, any such descriptor must <i>not</i> live on the program stack.

Typically, such a descriptor would be a component of an object which is allocated

on the heap. </p>

<p>The following diagram illustrates the general idea. In this case, there

are three parameters, one of which is an integer, and the other two being

pointers to descriptors. </p>

<fig id="GUID-C3369B01-2A0D-5AB2-973B-386FDBBB6B86">

<p>Inter-thread data transfer</p>

</fig>

<section id="GUID-EE636E39-A171-484D-AAF4-7996D04C8EEC"><title>See also</title> <p> <xref href="GUID-79BAF19D-F003-5468-9C01-6E918B06C36D.dita">Descriptor

concepts</xref>. </p> </section>

</conbody></concept>