signal vs threading.Event Wakeup: Localhost Lab

Intro — what this post promises

Wake latency with threading.Event vs a SIGUSR1 self-signal handler, plus signal.signal install cost. Measured on Linux localhost.

Related links:

• 01shoppercove.comcmath vs math hypot localhost lab
• 02shoppercove.comsqlite3 vs shelve localhost lab
• 03shoppercove.comgc collect cost localhost lab
• 04shoppercove.comcopy copy vs dict copy localhost lab
• 05shoppercove.comhtml parser vs regex localhost lab
• 06shoppercove.comdataclass asdict vs vars localhost lab
• 07shoppercove.comtracemalloc snapshot localhost lab
• 08shoppercove.comintenum vs int localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. These arms are not identical models: Event wakes a worker thread; SIGUSR1 runs a main-thread handler with a busy-wait until delivery. Numbers show order-of-magnitude wakeup cost, not a drop-in API swap.

Verdict up front (n=200 wakes): Event p50 ~11.2 µs; SIGUSR1 self-kill p50 ~2.2 µs. Handler install ~1092573 ops/s.

Arms

Seven rounds for install; wake arms use median of 200 one-shot latencies (complete=True).

Lab topology

n_wakes=200 · p50 latency
install: n=20000 × 7 rounds

Script: lab-evidence/135-signal-vs-event-wakeup/results/run_lab.py.

Lead table

Reading it for SRE work

• Cross-thread coordination in apps → threading.Event (or Condition/Queue) — safe and idiomatic.
• Integrating with C extensions / process supervision that already speak UNIX signals → measure handler work; keep handlers tiny.
• Do not replace Events with signals for normal Python concurrency — signal delivery rules (main thread only) will bite.
• Install cost (~1092573 ops/s) is cheap; handler body and reentrancy are the risk.

Methodology caveat

The signal arm busy-waits until the handler clears a flag, so it excludes scheduler sleep and can look faster than Event (~2.2 µs vs ~11.2 µs). Event includes thread wake scheduling. Treat this as “how expensive is a self-signal round trip vs an Event set,” not “signals beat threads.”

Operational guidance

Use signals for external process control (reload, graceful stop). Use Events for in-process wait/notify. Mixing them without a clear ownership map creates lost wakeups and main-thread-only surprises under load.

Keep signal handlers under a few microseconds of safe work — set a flag, write a byte to a wakeup fd — and do real processing on a normal thread. That discipline matters more than the ~2.2 µs self-kill number in this lab.

Install vs delivery

Rebinding signal.signal ran at ~1092573 ops/s — registration is not the bottleneck. Delivery semantics and handler safety are. Pair this lab with your process manager’s reload story: a SIGHUP that runs a full config parse in-handler will dominate any ~2.2 µs self-kill figure.

Pitfalls

• Doing heavy work inside signal handlers.
• Assuming signal latency from this busy-wait model applies to pause()/sigwait.
• Forgetting main-thread-only delivery in CPython.
• Comparing to lab 23 epoll/select I/O multiplexing (different problem).

Reproduce

python3 lab-evidence/135-signal-vs-event-wakeup/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box, same-process only. Not multiprocess kill storms, not realtime OS guarantees.

When in doubt, wake a queue or write to a self-pipe and keep the handler trivial.

Takeaway

Event wakeup p50 ~11.2 µs; SIGUSR1 self-signal p50 ~2.2 µs under a busy-wait delivery check. Prefer Event for Python thread coordination; reserve signal for process-level control with tiny handlers.