Skip to content
Calcrivo

Signal Delivery Time Calculator

Estimate signal delivery latency from queue depth and per-signal processing time.

Inputs

Estimated Delivery Time (µs)

40.00

Estimated Delivery Time (ms)

0.0400

Total Incl. Handler Overhead (µs)

56.00

Worst-Case Delay for Last Queued Signal (µs)

56.00

Step by step

  1. Values used

    Signal Queue Depth (pending signals) = 8; Processing Time per Signal (µs) = 5; Signal Handler Overhead (µs) = 2

  2. Signal delivery time

    delivery_time_us = signal_queue_depth × processing_time_per_signal

  3. Estimated Delivery Time (µs)

    = 40.00

  4. Estimated Delivery Time (ms)

    = 0.0400

  5. Total Incl. Handler Overhead (µs)

    = 56.00

  6. Worst-Case Delay for Last Queued Signal (µs)

    = 56.00

How it works

Standard (non-realtime) POSIX signals are not queued per-instance — multiple pending deliveries of the same signal collapse into one — but realtime signals (SIGRTMIN..SIGRTMAX) delivered via sigqueue(2) do queue, and a backlog of pending signals must each be dequeued and dispatched to a handler before the process resumes normal execution. This calculator models the cumulative delivery latency as queue depth multiplied by per-signal processing time, giving a rough worst-case bound for how long a process might spend just working through a signal backlog.

Formula

Signal delivery time

delivery_time_us = signal_queue_depth × processing_time_per_signal

Q_{depth}
pending signal queue depth
t_{signal}
processing time per signal (µs)

Frequently Asked Questions

Do regular signals like SIGTERM actually queue like this?

No — standard signals are binary pending flags; sending the same standard signal multiple times before delivery has no cumulative effect. Only realtime signals (SIGRTMIN through SIGRTMAX) queue multiple pending instances, which is what this calculator's queue-depth model best represents.

How can I inspect pending signals for a process?

`cat /proc/PID/status` shows `SigPnd` (thread-pending) and `ShdPnd` (process-wide pending) as hexadecimal bitmasks where each bit corresponds to a signal number.

What makes per-signal processing time vary?

Signal handler complexity, whether the handler must acquire locks, context-switch overhead if delivery requires waking a sleeping thread, and kernel signal-delivery path overhead (e.g. ptrace interception) all add to the effective per-signal cost beyond the bare minimum kernel dispatch time.

You might also need