When a task completes, the SEP that was running it invokes a stored procedure to remove the request that has just completed from the request queue, and get the next available request to execute (i.e. it is not the dispatcher that waits until a SEP becomes available to dispatch the next request, it is a running SEP that pops the next available request off the request queue).
The output from this request is sent directly from the SEP to the listener. If the response from the SEP is at the end of a task, the next client input for the same session will be routed to the dispatcher by the listener (that is, treated as a new request). If the response from the SEP is during task execution, the next client input for the same session will be routed directly to the SEP running the task by the listener.
A dispatcher can also be invoked by an event monitor to dispatch a scheduled task. A scheduled task gets created as a result of the START API. A timer is associated with a scheduled task. That is, the START API allows you to start a new task either at some time in the future, or immediately. When this timer expires, an event is posted by the cross-region database which gets picked up by an event monitor process. The event monitor invokes a dispatcher service passing it information about the scheduled task. The dispatcher builds and queues a request for the scheduled task in much the same way as it queues a request from a listener process.