Add a note to `AllocRef`, that implementation don't always has to be `'static`

[TimDiekmann]

In rust-lang/rust#79327 some 'static bounds were added to the Pin-API of Box. A note should be added somewhere (most likely to AllocRef, that this is not always required.

as we add allocator parameters, it can be easy to think that it'll always be 'static. Noting somewhere that this is not true explicitly I think would be good. Not directly related to Pin, though.

^{This is a reminder for me so that I don't forget to add it as soon as I have a chance.}

[jasta]

Found this issue after tearing my hair out trying to understand why Box::<_, A>::pin requires A: 'static. A common use case for me for the allocator_api is to create an allocator and use its reference like this:

let alloc = MyAlloc::new(...); // <-- MyAlloc does not implement Clone
let boxed_123 = Box::new_in(123, &alloc);
let boxed_456 = Box::new_in(123, &alloc);

But this approach means that A: 'static is not satisfied, and therefore I can't use Box::pin. I can't for the life of me understand why that requirement exists since it is not possible to have any Pin<Box, A> outlive the allocator since &alloc necessary can't outlive my alloc binding.

[RustyYato]

This is because Pin requires that Drop::drop is called before the underlying memory is freed, which can't be satisfied with non-owned allocations (such as local allocators).

[jasta]

I see, this implies 'static is overbearing. And to be clear, I agree an overbearing position is better than underspecified by default, I'm just trying to understand if Pin::new_unchecked in my case is in fact safe and/or are there opportunities to precisely specify the lifetime requirements of A.

If I understand things correctly, in my example there is a strict guarantee that T::drop is called before A::drop because Box<T, A>::drop cannot occur after A::drop (otherwise we have much more foundational issues in rust where Box could access self.alloc after the type's lifetime expires). And T::drop isn't safe until Box<T, A>::drop therefore T::drop always happens before A::drop>. Therefore Pin<Box<T, A>> guarantees that Box<T, A>::drop occurs before A::drop and since A is a &MyAlloc that means MyAlloc::drop necessarily follows T::drop.

What am I missing here? What case causes undefined behaviour if A: 'static isn't met with respect to Pin<Box<T, A>>?

[CAD97]

The TLDR of the issue is that if you forget the Box, you can then drop the (no longer) borrowed allocator without dropping the pinned object first. If dropping the allocator leaks any allocations which haven't been deallocated, this is fine. But if dropping the allocator will blanket release any memory it was managing, then you have broken the pinning guarantee.

The alternative to the A: 'static bounds is some kind of PinningAllocator which requires that any memory allocated with A will not be deallocated until deallocate is called or A is dropped. Fundamentally, &A cannot guarantee that.

[jasta]

I see, the issue then feels a little bit more like the same problem scoped threads are trying to solve. In the case of Pin and Allocator that's some way to guarantee that the pinned T will not be leaked beyond the usable scope of the Allocator. Whether that's through lifetimes or just through a contractual guarantee upheld by the caller is open to the implementer to decide. Box::into_pin, however, is choosing to uphold the strictest possible lifetime guarantee in the absence of any kind of documented alternatives to just not do the mem::forget and reclaim thing described above.

So my case should be safe so long as I internally manage the Pin and Box such that I can guarantee forget/ManuallyDrop are not used and thus Rust naturally guarantees T::drop is called before A::drop.

Thanks for the explanation, this helps a lot!

[jasta]

For context btw what I'm working on is similar to FuturesUnordered but with a couple simple slab allocators that can produce a maximum fixed number of Box and Arc instances. Thus library developers could now have a way to get a spawn-like programming model agnostic to any executor/runtime (think Embassy on bare metal or Tokio elsewhere), while still maintaining support for a statically sized and deterministic spawning model. Think like a simple server that would want to spawn a new future for each client but for memory constrained cases you'd want to say it can only allocate out of this small 1KiB pool of memory and will have to reject new clients when that is exceeded at runtime.

Again thanks for the help!