signals

Derives heuristic PoolSignals from these metrics using thresholds.

• PoolSignal.StarvationSuspected: pending > 0 and the queue-delay p95 is at or above SignalThresholds.starvationQueueDelayP95.

• PoolSignal.LongRunningSegment: DispatcherMetrics.longestRun is at or above SignalThresholds.longRunningSegment. On a CPU-bound dispatcher a long segment suggests a blocking call; see DISPATCH_001 and DISPATCH_002 in docs/BEST_PRACTICES_COROUTINES.md.

These are heuristics, not proof. The queue-delay p95 is a histogram bucket upper bound (up to 2x the real value), and queue delay is only recorded when a block STARTS. If every worker is blocked and nothing starts, the p95 stays at its old value and PoolSignal.StarvationSuspected may not fire; the trend signals (PoolSignal.BacklogGrowing, PoolSignal.PoolSaturated) from List<TraceEvent.PoolSample>.signals do catch that case. This function only looks at one snapshot; to detect trends over time use List<TraceEvent.PoolSample>.signals, fed by PoolSampler.

Example:

stats.metrics().flatMap { it.signals() }.forEach(::println)

Requires opting in to ExperimentalStructuredCoroutines.

Parameters

Derives heuristic PoolSignals from a chronological series of TraceEvent.PoolSamples, such as those a PoolSampler emits. Each label is evaluated on its own over its last minSamples samples; a label with fewer samples yields no signal.

• PoolSignal.BacklogGrowing: pending is non-decreasing across the window, ends higher than it started and is positive.

• PoolSignal.PoolSaturated: in every sample of the window parallelism is known, running >= parallelism and pending > 0.

These are heuristics, not proof: pending can overcount (see TraceEvent.PoolSample) and parallelism may be inferred. The result is ordered by the first appearance of each label.

Example:

val samples = ring.snapshot().filterIsInstance<TraceEvent.PoolSample>()
samples.signals().forEach(::println)

Parameters

Throws