How to schedule a task to run every hour with delay-timer?

Use the `set_frequency_repeated_by_cron_str` method with a cron expression like '0 * * * *' or the shorthand '@hourly' when building a task with `TaskBuilder`. This allows precise hourly execution similar to traditional cron jobs.

delay-timer vs tokio's interval for periodic tasks?

delay-timer offers more features like dynamic task management, cron-like scheduling, and parallelism control, while tokio's interval is simpler but limited to fixed intervals without runtime modifications. Choose delay-timer for complex scheduling needs.

How to handle errors and retries in delay-timer tasks?

Error handling must be implemented within the task closure itself; delay-timer does not provide built-in retry mechanisms. Developers need to manage failures manually, such as using try-catch blocks in async tasks or logging errors for debugging.

Can I use delay-timer in a synchronous Rust app without async runtime?

Yes, delay-timer supports synchronous tasks via `spawn_routine`, but for asynchronous tasks, an async runtime like smol or tokio is required. The builder allows configuration without default runtimes if only synchronous execution is needed.

What is the performance overhead of using delay-timer?

Based on the time wheel algorithm, it's efficient for managing many timed tasks, but overhead depends on task frequency and parallelism settings. The README notes benchmarks as a to-do item, so actual performance may vary and require testing.

How to monitor the status of scheduled tasks in delay-timer?

Monitoring is limited; developers can use task handles to check instances, but built-in dashboards or detailed logs are not provided. Implementing custom logging within tasks or external tools is recommended for production monitoring.

delay-timer — Rust Task Scheduler Library

What is delay-timer?

delay-timer is a Rust task scheduler built on a time wheel algorithm, designed to manage timed and periodic tasks. It provides a flexible alternative to cron-like schedulers by supporting both synchronous and asynchronous task execution, along with dynamic runtime task management.

Target Audience

Rust developers building applications that require scheduled, delayed, or recurring tasks, such as background job processors, periodic data backups, or timed automation scripts.

Value Proposition

Developers choose delay-timer for its dynamic task management, allowing tasks to be added, canceled, or removed at runtime without restarting the scheduler, and its flexibility in supporting both async/await and synchronous execution with optional runtimes like smol or tokio.

Time-manager of delayed tasks. Like crontab, but synchronous asynchronous tasks are possible scheduling, and dynamic add/cancel/remove is supported.

Use Cases

Best For

Scheduling periodic tasks with cron-like expressions in Rust applications
Managing dynamic task lifecycles where tasks need to be added or canceled at runtime
Running asynchronous background jobs with controlled parallelism
Executing tasks at specific dates and times, such as weekly backups
Building task schedulers that require fine-grained control over individual task instances
Integrating timed task management with async runtimes like tokio or smol

Not Ideal For

Projects requiring distributed task scheduling across multiple servers or nodes
Real-time systems where task execution timing must have nanosecond-level precision
Applications that need automatic task state persistence and recovery after crashes or restarts
Teams looking for out-of-the-box monitoring dashboards or extensive built-in logging features

Pros & Cons

Pros

Dynamic Task Management

Tasks can be added, canceled, or removed at runtime without restarting the scheduler, as shown with methods like `insert_task`, `remove_task`, and `cancel_with_wait` in the examples.

Flexible Async/Sync Support

Supports both asynchronous and synchronous task execution, with optional integration for smol or tokio runtimes, allowing developers to choose concurrency models based on their application needs.

Cron-like Scheduling

Enables scheduling using cron expressions (e.g., '@secondly') or specific dates and times, providing familiar and powerful timing controls beyond simple intervals.

Controlled Parallelism

Allows configuration of the maximum number of parallel tasks, preventing resource exhaustion and improving application stability, as demonstrated with `set_maximum_parallel_runnable_num`.

Cons

Incomplete Cleanup on Drop

The README's To Do List indicates that automatic termination of threads and tasks when the DelayTimer is dropped is not yet implemented, which could lead to resource leaks in long-running applications.

No Built-in Persistence

Task states are not persisted across application restarts, requiring manual re-adding of tasks after shutdowns or failures, which adds complexity for stateful scheduling needs.

Limited Monitoring Tools

Built-in features for monitoring task execution, such as detailed logs or metrics, are minimal, with 'report-for-server' listed as a future enhancement in the README.

Frequently Asked Questions

What is delay-timer?

Target Audience

Rust developers building applications that require scheduled, delayed, or recurring tasks, such as background job processors, periodic data backups, or timed automation scripts.

Value Proposition

Use Cases

Best For

Scheduling periodic tasks with cron-like expressions in Rust applications
Managing dynamic task lifecycles where tasks need to be added or canceled at runtime
Running asynchronous background jobs with controlled parallelism
Executing tasks at specific dates and times, such as weekly backups
Building task schedulers that require fine-grained control over individual task instances
Integrating timed task management with async runtimes like tokio or smol

Not Ideal For

Projects requiring distributed task scheduling across multiple servers or nodes
Real-time systems where task execution timing must have nanosecond-level precision
Applications that need automatic task state persistence and recovery after crashes or restarts
Teams looking for out-of-the-box monitoring dashboards or extensive built-in logging features

Pros & Cons

Pros

Dynamic Task Management

Tasks can be added, canceled, or removed at runtime without restarting the scheduler, as shown with methods like `insert_task`, `remove_task`, and `cancel_with_wait` in the examples.

Flexible Async/Sync Support

Supports both asynchronous and synchronous task execution, with optional integration for smol or tokio runtimes, allowing developers to choose concurrency models based on their application needs.

Cron-like Scheduling

Enables scheduling using cron expressions (e.g., '@secondly') or specific dates and times, providing familiar and powerful timing controls beyond simple intervals.

Controlled Parallelism

Allows configuration of the maximum number of parallel tasks, preventing resource exhaustion and improving application stability, as demonstrated with `set_maximum_parallel_runnable_num`.

Cons

Incomplete Cleanup on Drop

No Built-in Persistence

Task states are not persisted across application restarts, requiring manual re-adding of tasks after shutdowns or failures, which adds complexity for stateful scheduling needs.

Limited Monitoring Tools

Built-in features for monitoring task execution, such as detailed logs or metrics, are minimal, with 'report-for-server' listed as a future enhancement in the README.

Frequently Asked Questions

delay-timer

What is delay-timer?

Overview

Use Cases

Best For

Not Ideal For

Pros & Cons

Pros

Cons

Frequently Asked Questions

Found a gem we're missing?

delay-timer

What is delay-timer?

Overview

Use Cases

Best For

Not Ideal For

Pros & Cons

Pros

Cons

Frequently Asked Questions

Found a gem we're missing?