search

rust-lang / wg-allocators

Home of the Allocators working group: Paving a path for a standard set of allocator traits to be used in collections!
http://bit.ly/hello-wg-allocators
205 stars 9 forks source link

Scoped allocators and unwinding on OOM #62

Closed Ekleog closed 4 years ago

Ekleog commented 4 years ago

Hello,

A thought I just had: assume a rust server running multiple things on behalf of clients. It uses regular Rust code, that is not written to care specifically about this particular use case.

The server wants to limit the memory consumption clients could force upon it. It does so by having each client's allocations be in an arena allocator, and then wants to abort just that client's connection in case of OOM.

Unfortunately, this means that OOM must not abort the whole process, and that appears to be what the current behavior is, even with set_alloc_error_hook -- or at least so do the docs read like.

What would you think about making it possible for the alloc error hook to change the global allocator and then be allowed to unwind the stack? Or maybe it's already possible, and the docs that state that this function is invoked before the runtime aborts is just missing a part saying that it's actually possible, and that if this function doesn't return () then the runtime won't abort?

Ekleog commented 4 years ago

Uh, the message was sent earlier than I wanted it to… anyway, here comes the end of it.

Another thought I had in mind: what about actually making aborting the process part of the alloc error hook? This way it'd just take in a fn(Layout) -> !, and then there's no ambiguity in what happens, handle_alloc_error would really just call this hook.

Amanieu commented 4 years ago

See https://github.com/rust-lang/rust/issues/43596

Ekleog commented 4 years ago

Had missed this one, thank you!