Thread-relative +and Process-relative handles

diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C.dita Thu Jan 21 18:18:20 2010 +0000 @@ -0,0 +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.