Struct hv_stampede::PooledBump [−][src]
pub struct PooledBump<'s> { /* fields omitted */ }
Implementations
pub fn alloc_boxed<T>(&self, val: T) -> Box<'s, T>ⓘ
This function is unsafe because of the lifetimes involved: the bump arena itself must not
outlive the PooledBump
it came from.
Safety
You should only ever use this as a temp variable/middle step when allocating something
inside the PooledBump
.
Get access to the Bump
inside without allowing the reference to outlive the
PooledBump
. It’s important to note that objects allocated inside the returned &Bump
will
not be able to live for as long as 's
/the lifetime parameter of the PooledBump
. This is
because if used as an Allocator
, &'s Bump
from a PooledBump<'s>
will provide the 's
lifetime to objects such as alloc::boxed::Box
, which means they can live past the
lifetime of the PooledBump
, the PooledBump
is pulled from the pool into another thread,
the box deallocates, and then calls the .dealloc
fn on the PooledBump
… which is in
another thread, could be trying to allocate/etc., and runs into a race condition.
Consumes the PooledBump
and temporarily “shuns” the Bump
, placing it into a special
pool inside the BumpPool
which contains pools that are now detached and floating in a
thread without being Sync
but which can be returned to the “ready” pool once the entire
BumpPool
is reset. Unlike PooledBump::as_bump_unbound
, the returned &'s Bump
is
completely safe to use, including as an allocator - because the type &Bump
is non-Send
,
it’s now permanently locked to the thread it was detached in, and cannot be accessed from
another thread. That is, until its borrow ends, the BumpPool
is reset, and it returns to
the “ready” pool having been reset itself.