TimerThread only reclaims a Task's pooled slot when the task is popped at
its run_time. A task unscheduled after being pulled into the internal heap
therefore keeps its slot until run_time, and tasks that pile up in the
buckets while the thread sleeps on a far-future deadline are not consumed
(and thus not reclaimed) until that deadline. With large timeouts the live
Task count grows to ~ qps * timeout even though almost all of those tasks
were unscheduled long ago.
Add two independent, bounded reclamation paths:
- Heap sweep: when the internal heap grows past
brpc_timer_heap_sweep_min_size (default 4096) and has roughly doubled
since the last sweep, drop unscheduled tasks from it. The trigger is a
timer-thread-local heuristic, so the unschedule() hot path is unchanged
(no new shared atomics/contention). Amortized O(1) per task.
- Periodic wakeup: cap the sleep at brpc_timer_max_wakeup_interval_ms
(default 0 = disabled, legacy behavior) so the thread wakes up to drain
the buckets and sweep the heap even when every pending task is far in
the future. An empty heap still sleeps until woken by schedule().
Expose pending_task_count() and allocated_task_count() for observability,
and add unit tests covering both the heap-retention and bucket-accumulation
cases (each verified to fail with the corresponding fix disabled).
Bright Chen