OSF DCE Application Development Guide--Core Components

Topics in RPC Application Development
rpc_ss_swap_client_alloc_free(), client code must ensure that it has not been called
from a manager routine.
Deallocation of allocated storage returned from the client stubs is not automatic.
Therefore, client code must ensure that it uses the free routine that it specified in the call
to rpc_ss_swap_client_alloc_free() to deallocate each piece of allocated storage.
Client code that swaps in memory management routines with
rpc_ss_swap_client_alloc_free() should use the rpc_ss_set_client_alloc_free() routine
before it exits to restore the old allocation and free routines.
16.1.4 UsingThread Handles in Memory Management
There are two situations where control of memory management requires the use of thread
handles. The more common situation is when the manager thread spawns additional
threads. The less common situation is when a program transitions from being a client to
being a server, then reverts to being a client.
16.1.4.1 Spawning Threads
When a remote procedure call invokes the manager code, the manager code may wish to
spawn additional threads to complete the task for which it was called. To spawn
additional threads that are able to perform memory management, the manager code must
first call the rpc_ss_get_thread_handle( ) routine to get its thread handle and then pass
that thread handle to each spawned thread. Each spawned thread must call the rpc_ss_-
set_thread_handle( ) routine with the handle received from the manager code.
These routine calls allow the manager and its spawned threads to share a common
memory management environment. This common environment enables memory
allocated by the spawned threads to be used in returned parameters and causes all
allocations in the common memory management environment to be released when the
manager thread returns to the server stub.
The main manager thread must not return control to the server stub before all the threads
it spawned complete execution; otherwise, unpredictable results may occur.
The listener thread can cancel the main manager thread if the remote procedure call is
orphaned or if a cancellation occurs on the client side of the application. You should
code the main manager thread to terminate any spawned threads before it exits. The
code should anticipate exits caused by an unexpected exception or by being canceled.
Your code can handle all of these cases by including a TRY/FINALLY block to clean up
any spawned threads if a cancellation or other exception occurs. If unexpected
exceptions do not concern you, then your code can perform two steps. They are
disabling cancelability before threads are spawned followed by enabling cancelability
after the join operation finishes and after testing for any pending cancel operations.
Following this disable/enable sequence prevents routine pthread_join( ) from producing
a cancel point in a manager thread that has spawned threads which, in turn, share thread
124245 Tandem Computers Incorporated 16−5