You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?The text was updated successfully, but these errors were encountered: