Observe the following rules when defining pipes in IDL:
· Pipe types must only be parameters. In other words, pipes of pipes, arrays of pipes, and structures or unions containing pipes as members are illegal.
· A pipe cannot be a function result.
· The element type of a pipe cannot be a pointer or contain a pointer.
· The element type of a pipe cannot be a context_handle or handle_t type.
· A pipe type cannot be used in the definition of another type. For example, the following code fragment is illegal:
typedef
pipe char pipe_t;
typedef
pipe_t * pipe_p_t;
· A pipe type cannot have the transmit_as attribute.
· The element type of a pipe cannot have the transmit_as attribute.
· A pipe parameter can be passed by value or by reference. A pipe that is passed by reference (that is, has an * (asterisk)) cannot have the ptr or unique parameter attributes.
· Pipes that pass data from the client to the server must be processed in the order in which they occur in an operation's signature. All such pipes must be processed before data is sent from the server to the client.
· Pipes that pass data from the server to the client must be processed in the order in which they occur in an operation's signature. No such pipes must be processed until all data has been sent from the client to the server.
· Manager routines must reraise RPC pipe and communications exceptions so that client stub code and server stub code continue to execute properly.
For example, consider an interface that has an out pipe along with other out parameters. Suppose that the following sequence of events occurs:
- The manager routine closes the pipe by writing an empty chunk whose length is 0 (zero).
- The manager routine attempts to write another chunk of data to the pipe.
- The generated push routine raises the exception rpc_x_fault_pipe_closed.
- The manager routine catches the exception and does not reraise it.
- The manager routine exits normally.
- The server stub attempts to marshal the out parameters.
After this sequence, neither the server stub nor the client stub can continue to execute properly.
To avoid this situation, you must reraise the exception.
· A pipe cannot be used in an operation that has the broadcast or idempotent attribute.
· The element type of a pipe cannot be a conformant structure.
· The maximum length of pipe type IDs is 29 characters.