Guides design choices for resource lifecycles in Rust, covering RAII, lazy init, pooling, guards and cleanup.
- What it does
- This skill provides a design framework for deciding when a resource should be created, used and cleaned up. It maps lifecycle patterns such as RAII, lazy initialization, pooling, guards and transaction scopes to Rust mechanisms like Drop, OnceLock, LazyLock, r2d2 and deadpool. It also lists lifecycle events, pattern templates, common errors and anti-patterns, and points to related skills for ownership, concurrency, domain scoping and error handling.
- When to use it
- Use it when designing how a resource is created, shared and released, such as connection pools, lazy singletons, scoped guards or transaction boundaries. It is also useful when deciding cleanup responsibility and error behavior during cleanup.
- Requirements
- No scripts or tooling are required; it is an instructions-only reference. The examples assume Rust and mention crates such as r2d2 and deadpool, but nothing needs to be installed to read the guidance.
Resource Lifecycle
Layer 2: Design Choices
Core Question
When should this resource be created, used, and cleaned up?
Before implementing lifecycle:
- What's the resource's scope?
- Who owns the cleanup responsibility?
- What happens on error?
Lifecycle Pattern → Implementation
Thinking Prompt
Before designing lifecycle:
-
What's the resource cost?
- Cheap → create per use
- Expensive → pool or cache
- Global → lazy singleton
-
What's the scope?
- Function-local → stack allocation
- Request-scoped → passed or extracted
- Application-wide → static or Arc
-
What about errors?
- Cleanup must happen → Drop
- Cleanup is optional → explicit close
- Cleanup can fail → Result from close
Trace Up ↑
To domain constraints (Layer 3):
Trace Down ↓
To implementation (Layer 1):
Quick Reference
Lifecycle Events
Pattern Templates
RAII Guard
Lazy Singleton
Common Errors
Anti-Patterns
Related Skills