Ownership and borrowing: make release responsibility explicit

Consider a request buffer moving from a receiver to a decoder. If the decoder becomes the owner, the receiver must stop treating its old handle as an independently releasable resource. Otherwise both components might release the same allocation. Rust makes this transfer explicit through moves of non-Copy values; the original binding cannot subsequently be used as if ownership remained there. This is a language-level contract, not a claim that a physical payload is always copied or that its address always stays fixed during a move.

Copying a handle is not necessarily copying its payload. A cloned reference-counted handle can share the original allocation, whereas cloning an owned byte vector creates an independent element buffer. The API determines which operation occurs. Count release responsibilities and distinct allocations, not merely variable names. Also avoid equating ownership with stack placement: an owning value can contain a pointer to heap storage, and a compiler can optimize away physical storage while preserving the required observable semantics.

A decoder can inspect a caller-owned buffer without acquiring release responsibility. In safe Rust, a shared reference normally supports shared reading, while an exclusive mutable reference controls access to its referent during the relevant borrow. Borrow checking considers required uses rather than blindly making every borrow last until the closing brace. A lifetime parameter relates valid regions across an interface. It does not allocate storage, insert reference counting, or extend a local temporary so that a returned reference suddenly becomes sound.

Returning an owned result is often the right answer when a function constructs new data. Returning a borrow is appropriate when the result genuinely refers to data whose owner can outlive the caller's use. Choose based on the relationship you can prove, not on a preference for avoiding all copies. If a long-lived cache needs independent data, an explicit copy may be simpler and cheaper than retaining a very large source buffer through a tiny borrowed view. That is a retention tradeoff to measure.

Describe ownership at each boundary in ordinary words: the callee borrows for the duration of the call, retains an owned handle after return, or takes responsibility for destruction. Include early returns and partially initialized results. Destructors can provide deterministic cleanup along supported control-flow paths, but process termination, intentional leaks, and language-specific abort behavior prevent a universal promise that every destructor always runs. Safe Rust permits memory leaks; memory safety does not require bounded memory consumption or successful application-level cleanup.

In the queue lab, imagine each waiting request holding the sole owner of its input payload. Press Reset, set λ=3 and μ=1, predict a net increase of two retained payloads per second, then Play or Step. For the second experiment, press Reset before setting λ=1 and μ=3; predict that the restored four-job initial backlog drains in two seconds, then Play or Step. Changing ownership syntax cannot repair this sustained overload. The fluid diagram does not implement borrowing, moves, or destruction. Its purpose is to test the separate claim that retaining fewer waiting requests lowers their payload budget. Explain where a borrowed view would keep a larger owner's storage alive even after most contents were no longer needed.