The document discusses scheduling for a Boost.Pipeline. It has three main goals: high throughput, low latency, and handling requests in the proper order. It describes a pipeline with segments that can process requests. Threads execute the segments. The scheduler must yield threads between segments while preserving segment context, identify the slowest segment, and select the next ready segment with a non-empty queue to balance load.

1. Boost.Pipeline Scheduling
● read_socket | process_req | write_socket
● Goals:
– high throughput
– low latency
● Constraints:
– order of requests matter
– reentrancy of transformations are not
guaranteed

2. Legend
● Segment
● Thread executing segment
● Request
● Queue

3. Input
Pipeline setup

4. Threads working
Input

5. 21
Input
Yield to offender
Queue is full, Thread 2 must yield. Since the downstream
queue is offending, the third segment should be chosen.

6. 21
Input
Thread migrated to other
segment
Thread 2 now executes the third segment. However, the contex
of the transformation in the second segment is kept.

7. 21
Input
Managing slow threads
The work in the third segment is heavy, thread 2 falls behind.
Thread 1 should yield, but the offender segment is already
running.

8. 12
Input
Yield to other
This case thread 1 should choose the latest segment
in the pipeline with a non-empty input queue.

9. Requirements
● Yield between segments
(coroutines/fibers)
● Ability to pinpoint offender task,
check if it's already running
● Ability to tell which is the latest non-
running segment with non-empty input
queue (and execute it)

10. Extra: Low-load, low latency
● If the input frequency is low, application
writer should be able to opt for pass-
through mode: threads following the
leader follower pattern. Each request is
processed by the next available thread,
thread runs through the whole pipeline
and returns to the pool.
● No N-* transformation is allowed.