Allocators: Best Practices & Anti-Patterns

[jmctagger]

@matklad

You can imagine use all there at the same time:

fn handle(
  request: *Request, 
  arena: Allocator, 
  gpa: Allocator, 
  scratch: Allocator, 
) Response

• arena is for request-scoped stuff, that’s where Response is allocated in.
• gpa is for data that outlives a single request. For example, if requests share a cache, data in the cache is managed via gpa
• scratch is for data that is required to compute Response, but isn’t actual response. For example, if you need to sort something, you can use scratch to allocate that buffer.

In this case, would you consider the following variation wise or unwise (or “just depends”)?

const Allocators = struct {
  request: Allocator,
  state: Allocator,
  scratch: Allocator,
};
fn handle(request: *Request, allocators: Allocators) Response {
  const foo = allocators.scratch.alloc(u8, 64); // for my sort....
  // ....
}

(A “just depends” answer might be offered like: “if there are lots of handle_X() variations, and they follow this pattern, then this can be a useful construct”… but I’m looking more for reflection on the naming - instead of the names “arena” and “gpa”, here, we have a proposition that might be considered even more specific, or “suggestive” - that’s good, right? Drawbacks?)