3.2.5.2 Sequencing Rules

The following is a typical sequence of activity for a server's RunspacePool and pipeline

  1. The server creates a RunspacePool and the RunspacePool gets into the Opened state. Refer to sections 3.2.5.4.1 and 3.2.5.4.2 for more details.

  2. When a RunspacePool is in an Opened state, RunspacePool-specific messages such as SET_MAX_RUNSPACES (section 3.2.5.4.6), SET_MIN_RUNSPACES (section 3.2.5.4.7), and GET_AVAILABLE_RUNSPACES (section 3.2.5.4.11) can be received by the server's RunspacePool. For more details about which messages can be received, see section 3.2.5.4.

  3. When a RunspacePool is in an Opened state, a client can send a CREATE_PIPELINE (section 3.2.5.4.10) to the server to start executing a pipeline on the server. The server creates a pipeline and changes the pipeline state to Running.

  4. When the RunspacePool is in Opened state, a server can send RunspacePool-specific messages, such as RUNSPACEPOOL_HOST_CALL (section 3.2.5.4.15) and RUNSPACEPOOL_STATE (section 3.2.5.4.9).

  5. When a pipeline is in the Running state, a server can send pipeline-specific messages, such as PIPELINE_OUTPUT (section 3.2.5.4.19) and PIPELINE_HOST_CALL (section 3.2.5.4.27). For more details about the exact messages that can be received, see section 3.2.5.4.

  6. The server MAY choose to stop or fail a pipeline at any time (section 3.2.1.3.2) as long as the pipeline is in a Running state. After changing the state, the server MUST send a PIPELINE_STATE message (section 3.2.5.4.21) with the appropriate state information to the client.

  7. A server can close a RunspacePool and associated pipelines at any time, as long as the RunspacePool is in an Opened state. After changing the state, the server MUST send a RUNSPACEPOOL_STATE message (section 3.2.5.4.9) with appropriate state information to the client.

  8. When a RunspacePool is in a Closed state, that specific RunspacePool is not allowed for executing pipelines.