Description
PR #50880 added an API to override the std OOM handler, similarly to the panic hook. This was discussed previously in issue #49668, after PR #50144 moved OOM handling out of the Alloc
/GlobalAlloc
traits. The API is somewhat similar to what existed before PR #42727 removed it without an explanation. This issue tracks the stabilization of this API.
Defined in the std::alloc
module:
pub fn set_oom_hook(hook: fn(Layout) -> !);
pub fn take_oom_hook() -> fn(Layout) -> !;
pub fn set_alloc_error_hook(hook: fn(Layout));
pub fn take_alloc_error_hook() -> fn(Layout);
CC @rust-lang/libs, @SimonSapin
Unresolved questions
-
Name of the functions. The API before rustc: Implement the #[global_allocator] attribute #42727 usedMake the OOM hook return_handler
, I made it_hook
in OOM handling changes #50880 because that's the terminology used for the panic hook (OTOH, the panic hook returns, contrary to the OOM hook).()
rather than!
#51264 - Should this move to its own module, or stay in
std::alloc
? - Interaction with unwinding.
alloc::alloc::oom
is marked#[rustc_allocator_nounwind]
, so theoretically, the hook shouldn't panic (except when panic=abort). Yet if the hook does panic, unwinding seems to happen properly except it doesn't. - Should we have this, or Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) #51540, or both?
- Who is responsible for preventing reentrancy issues through the allocator? unsafe-code-guidelines#506
Metadata
Metadata
Assignees
Labels
Area: Custom and system allocatorsBlocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are tracked on the team's project board.Relevant to the library API team, which will review and decide on the PR/issue.