Agent Skills: Resource Lifecycle

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

| Pattern | When | Implementation | |---------|------|----------------| | RAII | Auto cleanup | Drop trait | | Lazy init | Deferred creation | OnceLock, LazyLock | | Pool | Reuse expensive resources | r2d2, deadpool | | Guard | Scoped access | MutexGuard pattern | | Scope | Transaction boundary | Custom struct + Drop |

Thinking Prompt

Before designing lifecycle:

1. What's the resource cost?

   • Cheap → create per use
   • Expensive → pool or cache
   • Global → lazy singleton

2. What's the scope?

   • Function-local → stack allocation
   • Request-scoped → passed or extracted
   • Application-wide → static or Arc

3. 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):

"How should I manage database connections?"
    ↑ Ask: What's the connection cost?
    ↑ Check: domain-* (latency requirements)
    ↑ Check: Infrastructure (connection limits)

| Question | Trace To | Ask | |----------|----------|-----| | Connection pooling | domain-* | What's acceptable latency? | | Resource limits | domain-* | What are infra constraints? | | Transaction scope | domain-* | What must be atomic? |

Trace Down ↓

To implementation (Layer 1):

"Need automatic cleanup"
    ↓ m02-resource: Implement Drop
    ↓ m01-ownership: Clear owner for cleanup

"Need lazy initialization"
    ↓ m03-mutability: OnceLock for thread-safe
    ↓ m07-concurrency: LazyLock for sync

"Need connection pool"
    ↓ m07-concurrency: Thread-safe pool
    ↓ m02-resource: Arc for sharing

Quick Reference

| Pattern | Type | Use Case | |---------|------|----------| | RAII | Drop trait | Auto cleanup on scope exit | | Lazy Init | OnceLock, LazyLock | Deferred initialization | | Pool | r2d2, deadpool | Connection reuse | | Guard | MutexGuard | Scoped lock release | | Scope | Custom struct | Transaction boundaries |

Lifecycle Events

| Event | Rust Mechanism | |-------|----------------| | Creation | new(), Default | | Lazy Init | OnceLock::get_or_init | | Usage | &self, &mut self | | Cleanup | Drop::drop() |

Pattern Templates

RAII Guard

struct FileGuard {
    path: PathBuf,
    _handle: File,
}

impl Drop for FileGuard {
    fn drop(&mut self) {
        // Cleanup: remove temp file
        let _ = std::fs::remove_file(&self.path);
    }
}

Lazy Singleton

use std::sync::OnceLock;

static CONFIG: OnceLock<Config> = OnceLock::new();

fn get_config() -> &'static Config {
    CONFIG.get_or_init(|| {
        Config::load().expect("config required")
    })
}

Common Errors

| Error | Cause | Fix | |-------|-------|-----| | Resource leak | Forgot Drop | Implement Drop or RAII wrapper | | Double free | Manual memory | Let Rust handle | | Use after drop | Dangling reference | Check lifetimes | | E0509 move out of Drop | Moving owned field | Option::take() | | Pool exhaustion | Not returned | Ensure Drop returns |

Anti-Patterns

| Anti-Pattern | Why Bad | Better | |--------------|---------|--------| | Manual cleanup | Easy to forget | RAII/Drop | | lazy_static! | External dep | std::sync::OnceLock | | Global mutable state | Thread unsafety | OnceLock or proper sync | | Forget to close | Resource leak | Drop impl |

Related Skills

| When | See | |------|-----| | Smart pointers | m02-resource | | Thread-safe init | m07-concurrency | | Domain scopes | m09-domain | | Error in cleanup | m06-error-handling |