diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita --- a/Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita Wed Mar 31 11:11:55 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita Fri Jun 11 12:39:03 2010 +0100 @@ -1,55 +1,55 @@ - - - - - -Thread-relative -and Process-relative handlesThis document describes the difference between thread-relative -and process-relative handles. -

This is the issue of handle ownership.

-

Threads and processes each maintain a list of objects to which they refer. -This list is an object index and is the way in which handle-numbers representing -these objects are generated.

-

When user code causes a Kernel object (e.g. a mutex) to be created, ownership -of the handle which is opened on that object may be vested either in the thread -or the process. If ownership is vested in the thread, the handle associated -with that object is said to be thread-relative, conversely, if ownership -is vested in the process, the handle associated with that object is said to -beprocess-relative.

-

The following diagram shows the case where code belonging to thread A creates -a mutex and vests ownership of the handle in the thread.

- -Thread-relative handle - - -

Compare with the following case where ownership of the mutex handle is -vested in the process.

- -Process-relative handle - - -

In both cases, the mutex object is added to the appropriate Kernel container -which can be considered as the owner of the object.

-

The significance of a process-relative handle is that any thread in the -process can use that handle to access the Kernel side object that the handle -represents. In contrast, a thread-relative handle can only be used by the -thread creating it; other threads in that process can only access the Kernel -side object by duplicating that -handle.

-

For a thread-relative handle, the associated Kernel side object is closed -if the thread dies. For a process-relative handle, the Kernel side object -is closed if the process dies. Such an object is not closed if any thread -belonging to that process dies; the object remains in existence for the lifetime -of the process, or until all references to it have been explicitly closed.

-

See also:

- + + + + + +Thread-relative +and Process-relative handlesThis document describes the difference between thread-relative +and process-relative handles. +

This is the issue of handle ownership.

+

Threads and processes each maintain a list of objects to which they refer. +This list is an object index and is the way in which handle-numbers representing +these objects are generated.

+

When user code causes a Kernel object (e.g. a mutex) to be created, ownership +of the handle which is opened on that object may be vested either in the thread +or the process. If ownership is vested in the thread, the handle associated +with that object is said to be thread-relative, conversely, if ownership +is vested in the process, the handle associated with that object is said to +beprocess-relative.

+

The following diagram shows the case where code belonging to thread A creates +a mutex and vests ownership of the handle in the thread.

+ +Thread-relative handle + + +

Compare with the following case where ownership of the mutex handle is +vested in the process.

+ +Process-relative handle + + +

In both cases, the mutex object is added to the appropriate Kernel container +which can be considered as the owner of the object.

+

The significance of a process-relative handle is that any thread in the +process can use that handle to access the Kernel side object that the handle +represents. In contrast, a thread-relative handle can only be used by the +thread creating it; other threads in that process can only access the Kernel +side object by duplicating that +handle.

+

For a thread-relative handle, the associated Kernel side object is closed +if the thread dies. For a process-relative handle, the Kernel side object +is closed if the process dies. Such an object is not closed if any thread +belonging to that process dies; the object remains in existence for the lifetime +of the process, or until all references to it have been explicitly closed.

+

See also:

+
    +
  • The +object index

  • +
\ No newline at end of file