How should a threading.Condition wait recompute its timeout after an early wake-up?

## Why the loop exists at all `threading.Condition.wait()` releases the condition's lock, blocks, and reacquires the lock before returning. It can return for reasons other than "the thing you were waiting for happened": another thread called `notify()` when your particular predicate was still false, several waiters were woken and another one consumed the work, or the platform delivered a spurious wake-up. Nothing about a return from `wait()` proves the predicate is now true. That is why the correct shape is always: ```python with cond: while not predicate(): cond.wait(timeout) ``` Given a timeout, `wait()` returns `False` if the timeout elapsed and `True` otherwise — but that return value tells you about the wait, not about your predicate, so the loop still has to check. ## The bug: re-passing the original timeout Look at what the loop above does when the predicate stays false. Each iteration passes the *full* `timeout` again. If notifications arrive every 10 ms and the predicate keeps evaluating false, a wait the caller believes is capped at 50 ms never terminates. The timeout has become a per-iteration limit instead of a total budget, and the caller's contract is silently broken. Under load — exactly when notifications are frequent — the wait gets longer, which is the worst possible failure direction. A second version of the same bug is subtler: keeping a running float budget and subtracting each measured slice from it. Take a warehouse pick-list builder whose collector waits for a batch of 340 pick lines before flushing. If each loop measures how long it slept and does `budget -= elapsed`, every iteration contributes its own rounding, and across many short wake-ups that floating-point drift accumulates in an unpredictable direction — the effective timeout is neither the requested one nor a stable one, and two runs of the same regression pack disagree about when the collector gave up. ## The fix: one absolute deadline, recomputed remainder Capture the deadline once, from a clock that cannot jump, and derive the remaining wait from it on every pass: ```python deadline = time.monotonic() + timeout with cond: while not predicate(): remaining = deadline - time.monotonic() if remaining <= 0: return False cond.wait(remaining) return True ``` Two properties fall out. First, the total wait is bounded by `timeout` no matter how many times the thread wakes, because every iteration measures against the same fixed origin — there is nothing to accumulate and therefore nothing to drift. Second, the check `remaining <= 0` before waiting handles the case where the deadline has already passed, which matters because passing a negative timeout is not a well-defined way to say "do not wait". ## Why the clock must be monotonic Computing `deadline = time.time() + timeout` reintroduces the wall clock's ability to jump into the middle of a blocking wait. An NTP step backwards while the thread is blocked leaves a deadline that is now further away than the caller asked for; a step forwards expires it immediately, and the waiter reports a timeout after a few milliseconds. `time.monotonic()` cannot move backwards and is not affected by the clock being set, which is exactly the guarantee a deadline needs. The one caveat worth naming is suspend: on some platforms the monotonic clock does not advance while the machine is asleep, so a laptop closed mid-wait may resume with the deadline barely moved. ## Do not hand-roll it if you do not have to `threading.Condition.wait_for(predicate, timeout)` does precisely this: it loops on the predicate, tracks an absolute deadline, waits on the remaining time, and returns the predicate's last value — `False` meaning it timed out. Most correct code should call that rather than re-deriving it. The hand-rolled form is worth knowing anyway, because the same shape appears everywhere a deadline crosses more than one blocking call: * a retry loop that must respect one overall budget across several attempts, rather than giving each attempt the full timeout * successive `queue.Queue.get(timeout=...)` calls that together must not exceed a caller's limit * a socket read loop where each read gets the remaining time, not the original * `asyncio.timeout()` (3.11+), which is the async-side expression of the same idea: it computes an absolute deadline against the event loop's own monotonic clock and applies it to everything inside the block, rather than to each await separately. ## What an interviewer is listening for The signal is not the code. It is whether you distinguish a *timeout* — a per-call parameter — from a *deadline*, an absolute point that survives across calls, and whether you know that any wait can return early so the predicate, not the return value, decides.