Post rebase tweaks.

src/user-guide/running-workflows/index.rst

@@ -12,10 +12,10 @@ Running Workflows
    retrying-tasks
    tracking-task-state
    workflow-completion
-   dynamic-behaviour.rst
    reflow
    simulation-modes
    scheduler-log-files
    dynamic-behaviour
+   authentication-files
    workflow-databases
    handling-job-preemption

src/user-guide/writing-workflows/scheduler.rst

@@ -125,23 +125,17 @@ External Command Execution
 --------------------------
 
 Job submission commands, event handlers, and job poll and kill commands, are
-executed by the :term:`scheduler` in a "pool" of asynchronous
-subprocesses, in order to avoid blocking the workflow process.
-
-The process pool
-is actively managed to limit it to a configurable size, using
-:cylc:conf:`global.cylc[scheduler]process pool size`.
-
-Custom event handlers should be lightweight and quick-running because they
-will tie up a process pool member until they complete, and the workflow will
-appear to stall if the pool is saturated with long-running processes.
-However, to guard against rogue commands that hang indefinitely, processes
-are killed after a configurable timeout
-(:cylc:conf:`global.cylc[scheduler]process pool timeout`).
-
-All process kills are
-logged by the :term:`scheduler`. For killed job submissions, the associated
-tasks also go to the *submit-failed* state.
+executed by the :term:`scheduler` in a subprocess pool. The pool is size can
+be configured with :cylc:conf:`global.cylc[scheduler]process pool size`.
+
+Event handlers should be lightweight and quick-running because they tie up
+a process pool member until complete, and the workflow will appear to stall if
+the pool is saturated with long-running processes.
+
+To protect the scheduler, processes are killed on a timeout
+(:cylc:conf:`global.cylc[scheduler]process pool timeout`). This will be
+logged by the :term:`scheduler`. If a job submission gets killed, the
+associated task goes to the ``submit-failed`` state.
 
 
 .. _Submitting Workflows To a Pool Of Hosts: