I'm reviewing #649. I'm coming back here to learn more about the exact requirements, based on high-level concerns related to this added comment in #649:

After this method is called, the caller is responsible for calling :meth:close when done using this buffer, otherwise there would be a memory leak!

• Do we really have to open this hole? In complex applications, it's only a matter of time for accidents to happen.

• If we give away ownership of mr, then ptr could become a dangling pointer.

Quoting from the issue description here:

This could interfere with projects such as nvmath-python and nvSHMEM who require explicit control over the buffer lifetime and deallocation timing.

What exactly are the requirements?

explicit control over the buffer lifetime

For keeping the buffer alive: Keeping a (Python) reference to the Buffer object will do that.

deallocation timing

Calling buf.close() will do that.

I'm trying to guess: Do you have a situation in which you cannot keep the Python reference around, and therefore cannot keep the Buffer object alive, or call any methods?

We discussed in the Thursday design meeting this week, summarizing here with more context.

Today we have 2 ways to trigger the destructor of Buffer to deallocate it and return the memory back to the MR:

1. Explicitly call the .close() method, or
2. When the refcount goes to zero, the finalizer kicks in automatically
   • This is meant to be a fallback because we do want users to call .close()

The semantics of the proposed .release() is: If it is called, the 2nd way of deallocation is no longer available. If users don't call .close() the memory will leak and not return to the MR.

• In the Tuesday team meeting, this was referred to by me as a "std::shared_ptr::reset()-like behavior," where we have a backdoor for users to explicit manage the object lifetime themselves, and not bound by the language constructs (C++ or Python destructor). This viewpoint was discussed/agreed upon in an internal Python/C++ meeting prior to opening this issue.

The use cases that this proposal can help include

• buffer deallocation that must not rely on refcounts, as the triggering time of garbage collector can be non-deterministic
• libraries requiring users to explicitly call a custom, library-provided free() function that wraps Buffer.close(), in which case the library expectation is its free() must be called

Originally nvshmem4py was meant to be the first adopter of this proposal, because their use case meets both scenarios above:

• nvSHMEM buffers must have precise, deterministic deallocation timing due to its collective nature
• nvshmem4py has a library-wide free() function that its users must call

However, during the design meeting we found that nvshmem4py internally holds (strong) references to the allocated buffers, and the way its free() is implemented is to just remove the internal reference. Therefore, it is unlikely that the proposed .release() could make any difference given the current nvshmem4py implementation, as there is no way for the buffers to be have zero refcount and thus garbage collected.

I believe the use cases listed above are legit (for example, nvshmem4py could choose to hold weak instead of strong references, like shmem4py). However, we agreed to put this proposal on hold until other user requests appear.