What does signal.setitimer with signal.ITIMER_REAL do that signal.alarm cannot?

`signal.alarm` is the minimal interface to a much richer Unix facility. `signal.setitimer` exposes the rest of it, and the three things it adds are fractional resolution, repetition, and a choice of clock. ### The signature ```python signal.setitimer(which, seconds, interval=0.0) ``` `which` selects one of three timers. `seconds` is a float giving the delay until the first delivery; passing `0` disarms the timer. `interval` is a float giving the gap between subsequent deliveries; leave it at `0.0` for a one-shot. The return value is the `(delay, interval)` pair that was previously armed, and `signal.getitimer(which)` reads the same pair without changing anything. Invalid values raise `signal.ItimerError`, a subclass of `OSError` — `signal.setitimer(signal.ITIMER_REAL, -1)` is the easy way to see it. ### The three timers **`signal.ITIMER_REAL`** counts wall-clock time and delivers `SIGALRM`. This is the one you want for a deadline: it does not care whether your process was running, sleeping, or descheduled. It is also, importantly, the *same* kernel timer that `signal.alarm` drives. Arming one cancels the other, and `signal.getitimer(signal.ITIMER_REAL)` will show the remaining time of an alarm set with `signal.alarm`. Treat them as two spellings of one resource. **`signal.ITIMER_VIRTUAL`** counts only the time the process spends executing in user mode, and delivers `SIGVTALRM`. A process blocked on I/O accumulates nothing. This is a profiling clock, not a deadline clock: it answers "how much CPU have I burned" rather than "how much time has passed". **`signal.ITIMER_PROF`** counts user plus system time and delivers `SIGPROF`. It is what sampling profilers historically used, since a tick every few milliseconds of CPU gives you a stack sample proportional to CPU consumption. Both of the CPU-based timers are per-process, and in a multi-threaded process the accounting sums across threads while the handler still runs only on the main thread. ### Fractional deadlines The practical reason to reach for `setitimer` in ordinary code is that `signal.alarm(0.5)` is a `TypeError` — it takes an integer count of seconds. A one-second floor is far too coarse for bounding, say, a single sensor read that normally completes in eight milliseconds. `signal.setitimer(signal.ITIMER_REAL, 0.05)` gives you the deadline you actually meant. Resolution beyond that is the kernel's business; the value is rounded to the timer's granularity, and delivery is a lower bound, not a promise — a busy machine can be late. ### Repetition, and the discipline it needs A non-zero `interval` turns the timer into a heartbeat. The classic uses are a watchdog that checks a liveness flag, a periodic flush, and a sampling profiler. Two rules keep it safe. First, **the handler must be tiny**. It runs in the main thread between bytecodes, so everything else in that thread is stalled while it runs, and a handler that takes longer than the interval means ticks arrive faster than you can consume them. The signal is not queued: several deliveries during one slow handler collapse into one. So set a flag, append to a preallocated list, or bump a counter — and do the real work in the normal control flow. Second, **disarm explicitly**. `signal.setitimer(signal.ITIMER_REAL, 0)` stops it. A repeating timer left armed keeps interrupting the process for its entire remaining life, which is a far noisier failure than a stale one-shot alarm. ### When to prefer something else A repeating `SIGALRM` is main-thread-only and Unix-only, and it perturbs whatever the main thread is doing. If all you need is "call this function every N seconds" and you are not trying to interrupt anything, a `threading.Timer` that re-arms itself, or a plain loop in a dedicated thread, is simpler, portable, and does not collide with any other user of `SIGALRM` in the process. Reach for `setitimer` when the point is precisely to interrupt the main thread — a deadline on a call that offers none, or a sampling tick that must land inside whatever code is running.