Symbian3/SDK/Source/GUID-6408C26A-2736-59A9-B785-6B119143619B.dita
changeset 8 ae94777fff8f
parent 7 51a74ef9ed63
child 13 48780e181b38
--- a/Symbian3/SDK/Source/GUID-6408C26A-2736-59A9-B785-6B119143619B.dita	Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-6408C26A-2736-59A9-B785-6B119143619B.dita	Fri Jun 11 12:39:03 2010 +0100
@@ -1,76 +1,76 @@
-<?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-6408C26A-2736-59A9-B785-6B119143619B" xml:lang="en"><title>How
-to use a thread-death notifier</title><shortdesc>Describes the thread-death notifier and provides a code snippet
-to show you how to use it.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>To use a thread-death notifier, a thread which needs to know about the
-death of other threads: </p>
-<ul>
-<li id="GUID-914D2BE7-BFD3-58E3-ABD4-53371512332F"><p>constructs an <codeph>RUndertaker</codeph> handle
-and then calls its <codeph>Create()</codeph> member function to create the
-associated Kernel side object. The <codeph>RUndertaker</codeph> handle is <keyword>process-relative</keyword> which
-means that the handle is <i>not</i> closed if the requesting thread dies. </p> </li>
-<li id="GUID-F46FEA42-38C3-526D-AC05-225BDD3A8714"><p>issues a notification
-request to the thread-death notifier, passing a reference to a <codeph>TRequestStatus</codeph> object
-and a reference to a <codeph>TInt</codeph>. </p> </li>
-</ul>
-<p>When any other thread dies, the requesting thread's <keyword>request semaphore</keyword> is
-signalled to indicate that the notification request is complete. The <codeph>TRequestStatus</codeph> object
-supplied by the requesting thread is set to <codeph>KErrDied</codeph>. </p>
-<p>In addition, the Kernel opens a local thread-relative handle on the dying
-thread. (thread-relative, here, means relative to the requesting thread) and
-sets the <codeph>TInt</codeph>, supplied by the requesting thread, to the
-resulting handle-number. The requesting thread can construct an <codeph>RThread</codeph> from
-this handle-number. The following diagram helps visualise the situation. </p>
-<fig id="GUID-5B53CA3B-5365-5C54-B2BC-EA8BA684F15E">
-<title>           Thread-death notifier         </title>
-<image href="GUID-70483E81-311F-5247-9F39-3940F20C0EB1_d0e242598_href.png" placement="inline"/>
-</fig>
-<p>The following code fragments demonstrate this: </p>
-<codeblock id="GUID-B5A219AD-CC59-50CE-A65B-0D3F4FD32F7A" xml:space="preserve">{
-...
-RUndertaker     the_undertaker;
-TRequestStatus  the_status;
-TInt            the_dyingthread_handle_number;
-...
-the_undertaker.Create();
-the_undertaker.Logon(the_status,the_dyingthread_handle_number);
-User::WaitForRequest(the_status);
-...
-...// prepare for a long wait
-...
-RThread r;
-r.SetHandle(the_dyingthread_handle_number);
-...
-...// Now have an open thread-relative handle to the
-...// dying thread so we can, for example, ...
-if (r.ExitReason()==0x666)
-    {
-    ...
-    }
-...// We have an open handle on the dying thread; the dying thread
-...// remains in existence until we close it.
-r.Close();
-...
-}</codeblock>
-<p>In practical code, an <codeph>RUndertaker</codeph> is used by an active
-object. </p>
-<p>The <codeph>RUndertaker</codeph> handle also offers a <codeph>LogonCancel()</codeph> function.
-Calling this function, causes the requesting thread's <keyword>request semaphore</keyword> to
-be signalled and any wait to complete. The <codeph>TRequestStatus</codeph> is
-set to <codeph>KErrCancel</codeph>. </p>
-<p>This technique of using an <codeph>RUndertaker</codeph> is not guaranteed
-to report the death of all threads. In particular, if a second thread dies
-while a requesting thread is handling the request completion due to the death
-of a first thread (but before it can make another notification request), the
-death of this second thread will go unnoticed. </p>
+<?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-6408C26A-2736-59A9-B785-6B119143619B" xml:lang="en"><title>How
+to use a thread-death notifier</title><shortdesc>Describes the thread-death notifier and provides a code snippet
+to show you how to use it.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>To use a thread-death notifier, a thread which needs to know about the
+death of other threads: </p>
+<ul>
+<li id="GUID-914D2BE7-BFD3-58E3-ABD4-53371512332F"><p>constructs an <codeph>RUndertaker</codeph> handle
+and then calls its <codeph>Create()</codeph> member function to create the
+associated Kernel side object. The <codeph>RUndertaker</codeph> handle is <keyword>process-relative</keyword> which
+means that the handle is <i>not</i> closed if the requesting thread dies. </p> </li>
+<li id="GUID-F46FEA42-38C3-526D-AC05-225BDD3A8714"><p>issues a notification
+request to the thread-death notifier, passing a reference to a <codeph>TRequestStatus</codeph> object
+and a reference to a <codeph>TInt</codeph>. </p> </li>
+</ul>
+<p>When any other thread dies, the requesting thread's <keyword>request semaphore</keyword> is
+signalled to indicate that the notification request is complete. The <codeph>TRequestStatus</codeph> object
+supplied by the requesting thread is set to <codeph>KErrDied</codeph>. </p>
+<p>In addition, the Kernel opens a local thread-relative handle on the dying
+thread. (thread-relative, here, means relative to the requesting thread) and
+sets the <codeph>TInt</codeph>, supplied by the requesting thread, to the
+resulting handle-number. The requesting thread can construct an <codeph>RThread</codeph> from
+this handle-number. The following diagram helps visualise the situation. </p>
+<fig id="GUID-5B53CA3B-5365-5C54-B2BC-EA8BA684F15E">
+<title>           Thread-death notifier         </title>
+<image href="GUID-70483E81-311F-5247-9F39-3940F20C0EB1_d0e238861_href.png" placement="inline"/>
+</fig>
+<p>The following code fragments demonstrate this: </p>
+<codeblock id="GUID-B5A219AD-CC59-50CE-A65B-0D3F4FD32F7A" xml:space="preserve">{
+...
+RUndertaker     the_undertaker;
+TRequestStatus  the_status;
+TInt            the_dyingthread_handle_number;
+...
+the_undertaker.Create();
+the_undertaker.Logon(the_status,the_dyingthread_handle_number);
+User::WaitForRequest(the_status);
+...
+...// prepare for a long wait
+...
+RThread r;
+r.SetHandle(the_dyingthread_handle_number);
+...
+...// Now have an open thread-relative handle to the
+...// dying thread so we can, for example, ...
+if (r.ExitReason()==0x666)
+    {
+    ...
+    }
+...// We have an open handle on the dying thread; the dying thread
+...// remains in existence until we close it.
+r.Close();
+...
+}</codeblock>
+<p>In practical code, an <codeph>RUndertaker</codeph> is used by an active
+object. </p>
+<p>The <codeph>RUndertaker</codeph> handle also offers a <codeph>LogonCancel()</codeph> function.
+Calling this function, causes the requesting thread's <keyword>request semaphore</keyword> to
+be signalled and any wait to complete. The <codeph>TRequestStatus</codeph> is
+set to <codeph>KErrCancel</codeph>. </p>
+<p>This technique of using an <codeph>RUndertaker</codeph> is not guaranteed
+to report the death of all threads. In particular, if a second thread dies
+while a requesting thread is handling the request completion due to the death
+of a first thread (but before it can make another notification request), the
+death of this second thread will go unnoticed. </p>
 </conbody></concept>
\ No newline at end of file