Edit

context_handle_noserialize attribute

  • Article

The [context_handle_noserialize] ACF attribute guarantees that a context handle will never be serialized, regardless of the application's default behavior.

typedef [context_handle_noserialize [ , type-acf-attribute-list ] ] context-handle-type

[context_handle_noserialize [, function-acf-attribute-list ] ] function-name( );

function-name (   [context_handle_noserialize 
  [ , parameter-acf-attribute-list ] ] param-name );

Parameters

type-acf-attribute-list

Any other ACF attributes that apply to the type.

context-handle-type

The identifier that specifies the context handle type, as defined in a typedef declaration. This is the type that receives the [context_handle] attribute in the IDL file.

function-acf-attribute-list

Any additional ACF attributes that apply to the function.

function-name

The name of the function as defined in the IDL file.

parameter-acf-attribute-list

Any other ACF attributes that apply to the parameter.

param-name

The name of the parameter as defined in the IDL file.

Remarks

The [context_handle] attribute identifies a binding handle that maintains context, or state information, on the server between remote procedure calls. The attribute can appear as an IDL typedef type attribute, as a function return type attribute, or as a parameter attribute.

By default, calls on context handles are serialized. An application can call RpcSsDontSerializeContext to override this default behavior. Using the [context_handle] attribute in an ACF file guarantees that calls on this particular context handle will not be serialized, regardless of the calling application's behavior. Providing a context rundown routine is optional.

This attribute is available in MIDL version 5.0.

Windows Server 2003 and Windows XP or later: A single interface can accommodate both serialized and nonserialized context handles, enabling one method on an interface to access a context handle exclusively (serialized), while other methods access that context handle in shared mode (nonserialized). These access capabilities are comparable to read/write locking mechanisms; methods using a serialized context handle are exclusive users (writers), whereas methods using a nonserialized context handle are shared users (readers). Methods that destroy or modify the state of a context handle must be serialized. Methods that do not modify the state of a context handle, such as those methods that simply read from a context handle, can be nonserialized. Note that creation methods are implicitly serialized.

Examples

typedef [context_handle_noserialize] PCONTEXT_HANDLE_TYPE; 
HRESULT RemoteFunc([context_handle_noserialize] pCxHandle);

See also

ACF Attributes

context_handle_serialize

context_handle

Context Handles

RpcSsDontSerializeContext

Server Context Run-down Routine

Multithreaded Clients and Context Handles

typedef