M02 Resource Agent Skill

Resource Management

> Layer 1: Language Mechanics

Core Question

What ownership pattern does this resource need?

Before choosing a smart pointer, understand:

• Is ownership single or shared?
• Is access single-threaded or multi-threaded?
• Are there potential cycles?

Error → Design Question

| Error | Don't Just Say | Ask Instead |

|-------|----------------|-------------|

| "Need heap allocation" | "Use Box" | Why can't this be on stack? |

| Rc memory leak | "Use Weak" | Is the cycle necessary in design? |

| RefCell panic | "Use try_borrow" | Is runtime check the right approach? |

| Arc overhead complaint | "Accept it" | Is multi-thread access actually needed? |

Thinking Prompt

Before choosing a smart pointer:

• What's the ownership model?
• Single owner → Box or owned value
• Shared ownership → Rc/Arc
• Weak reference → Weak

• What's the thread context?
• Single-thread → Rc, Cell, RefCell
• Multi-thread → Arc, Mutex, RwLock

• Are there cycles?
• Yes → One direction must be Weak
• No → Regular Rc/Arc is fine

Trace Up ↑

When pointer choice is unclear, trace to design:

"Should I use Arc or Rc?"
    ↑ Ask: Is this data shared across threads?
    ↑ Check: m07-concurrency (thread model)
    ↑ Check: domain-* (performance constraints)

| Situation | Trace To | Question |

|-----------|----------|----------|

| Rc vs Arc confusion | m07-concurrency | What's the concurrency model? |

| RefCell panics | m03-mutability | Is interior mutability right here? |

| Memory leaks | m12-lifecycle | Where should cleanup happen? |

Trace Down ↓

From design to implementation:

"Need single-owner heap data"
    ↓ Use: Box<T>

"Need shared immutable data (single-thread)"
    ↓ Use: Rc<T>

"Need shared immutable data (multi-thread)"
    ↓ Use: Arc<T>

"Need to break reference cycle"
    ↓ Use: Weak<T>

"Need shared mutable data"
    ↓ Single-thread: Rc<RefCell<T>>
    ↓ Multi-thread: Arc<Mutex<T>> or Arc<RwLock<T>>

Quick Reference

| Type | Ownership | Thread-Safe | Use When |

|------|-----------|-------------|----------|

| Box<T> | Single | Yes | Heap allocation, recursive types |

| Rc<T> | Shared | No | Single-thread shared ownership |

| Arc<T> | Shared | Yes | Multi-thread shared ownership |

| Weak<T> | Weak ref | Same as Rc/Arc | Break reference cycles |

| Cell<T> | Single | No | Interior mutability (Copy types) |

| RefCell<T> | Single | No | Interior mutability (runtime check) |

Decision Flowchart

Need heap allocation?
├─ Yes → Single owner?
│        ├─ Yes → Box<T>
│        └─ No → Multi-thread?
│                ├─ Yes → Arc<T>
│                └─ No → Rc<T>
└─ No → Stack allocation (default)

Have reference cycles?
├─ Yes → Use Weak for one direction
└─ No → Regular Rc/Arc

Need interior mutability?
├─ Yes → Thread-safe needed?
│        ├─ Yes → Mutex<T> or RwLock<T>
│        └─ No → T: Copy? → Cell<T> : RefCell<T>
└─ No → Use &mut T

Common Errors

| Problem | Cause | Fix |

|---------|-------|-----|

| Rc cycle leak | Mutual strong refs | Use Weak for one direction |

| RefCell panic | Borrow conflict at runtime | Use try_borrow or restructure |

| Arc overhead | Atomic ops in hot path | Consider Rc if single-threaded |

| Box unnecessary | Data fits on stack | Remove Box |

Anti-Patterns

| Anti-Pattern | Why Bad | Better |

|--------------|---------|--------|

| Arc everywhere | Unnecessary atomic overhead | Use Rc for single-thread |

| RefCell everywhere | Runtime panics | Design clear ownership |

| Box for small types | Unnecessary allocation | Stack allocation |

| Ignore Weak for cycles | Memory leaks | Design parent-child with Weak |

Related Skills

| When | See |

|------|-----|

| Ownership errors | m01-ownership |

| Interior mutability details | m03-mutability |

| Multi-thread context | m07-concurrency |

| Resource lifecycle | m12-lifecycle |