--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,56 @@
+<?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">
+<image href="GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e212448_href.png" placement="inline"/>
+<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>
\ No newline at end of file