That `PyMemAllocatorEx` looks almost exactly like one of the two variants I was proposing. Is there a reason for wanting to define our own structure vs just using that one?
I think the NEP should at least offer a brief comparison to that structure, even if we ultimately end up not using it.
> That all looks like it can be customized in theory. But I am not sure
> that it is practical, except for hooking and calling the previous one.
Is chaining allocators not likely something we want to support too? For instance, an allocator that is used for large arrays, but falls back to the previous one for small arrays?
> I have to say it feels a bit
> like exposing things publicly, that are really mainly used internally,
> but not sure... Presumably Python uses the `ctx` for something though.
I'd argue `ctx` / `baton` / `user_data` arguments are an essential part of any C callback API.
I can't find any particularly good reference for this right now, but I have been bitten multiple times by C APIs that forget to add this argument.
> If someone wants a different strategy (i.e. different alignment) they create a new policy
The crux of the problem here is that without very nasty hacks, C and C++ do not allow new functions to be created at runtime.
This makes it very awkward to write a parameterizable allocator. If you want to create two aligned allocators with different alignments, and you don't have a `ctx` argument to plumb through that alignment information, you're forced to write the entire thing twice.
> I guess the C++ similarity may be a reason, but I am not familiar with that.
Similarity isn't the only motivation - I was considering compatibility. Consider a user who's already written a shiny stateful C++ allocator, and wants to use it with numpy.
The NEP version has a bug that is very hard to fix without duplicating the entire `numpy_handler_from_cpp_allocator` function.
If compatibility with C++ seems too much of a stretch, the NEP API is not even compatible with `PyMemAllocatorEx`.
> But right now the proposal says this is static, and I honestly don't
> see much reason for it to be freeable? The current use-cases `cupy` or
> `pnumpy` don't not seem to need it.
I don't know much about either of these use cases, so the following is speculative.
In cupy, presumably the application is to tie allocation to a specific GPU device.
Presumably then, somewhere in the python code there is a handle to a GPU object, through which the allocators operate.
If that handle is stored in the allocator, and the allocator is freeable, then it is possible to write code that automatically releases the GPU handle after the allocator has been restored to the default and the last array using it is cleaned up.
If that cupy use-case seems somwhat plausible, then I think we should go with the PyObject approach.
If it doesn't seem plausible, then I think the `ctx` approach is acceptable, and we should consider declaring our struct
```struct {
PyMemAllocatorEx allocator; char const *name; }``` to reuse the existing python API unless there's a reason not to.
Eric