scheduled-thread-pool

scheduled-thread-pool is a small Rust library providing a thread pool that can schedule work to execute after a delay and optionally repeat it periodically. It lets you submit closures to run once at a future instant, at a fixed rate, or with a fixed delay between runs, all executed across a fixed set of worker threads. It underpins timer and background-maintenance needs in projects such as the r2d2 connection pool, where connections must be reaped and refreshed on a schedule.

What You Get

• A fixed-size ScheduledThreadPool that executes submitted jobs on worker threads
• One-shot scheduling that runs a closure after a specified delay
• Fixed-rate and fixed-delay scheduling for periodic recurring tasks
• Job handles that let you cancel a scheduled or repeating task

Common Use Cases

• Periodically reaping idle or broken resources in a connection pool
• Running recurring maintenance or heartbeat tasks in the background
• Deferring a piece of work to execute after a timeout

Under The Hood

Architecture

The pool is built around a shared, mutex-guarded binary heap of pending jobs ordered by their next execution instant, plus a set of worker threads. A dedicated coordination path waits until the earliest job is due, hands it to an available worker, and, for recurring jobs, reschedules the next occurrence according to fixed-rate or fixed-delay semantics before going back to sleep on a condition variable. Scheduling methods return a JobHandle whose cancellation flag is checked before a job runs.

Tech Stack

Pure Rust with a very small dependency footprint, using standard-library threading, synchronization primitives, and time types. It is dual-licensed Apache-2.0/MIT, targets stable Rust, and is structured as just a couple of source files (lib.rs and a builder) to stay lightweight as a dependency of other crates.

Code Quality

The code is compact and readable at roughly two source files, with an integration test validating delayed and periodic execution behavior. Its correctness matters because widely used crates depend on it; the narrow API surface and reliance on well-understood std synchronization primitives keep it easy to reason about despite infrequent releases.

API Design

The API is intentionally spare: create a pool with a worker count, then call execute_after, execute_at_fixed_rate, or execute_with_fixed_delay with a Duration and a closure. Returned handles make cancellation explicit, and because it mirrors familiar scheduled-executor concepts from other languages, developers can adopt it with almost no ramp-up.