jvanstraten commented on a change in pull request #12116:
URL: https://github.com/apache/arrow/pull/12116#discussion_r806166409
##########
File path: cpp/src/arrow/device.h
##########
@@ -223,4 +236,55 @@ class ARROW_EXPORT CPUMemoryManager : public MemoryManager
{
ARROW_EXPORT
std::shared_ptr<MemoryManager> default_cpu_memory_manager();
+/// A memory manager that uses the immutable zeros interface of the given
memory pool,
+/// rather than the normal mutable buffer interface.
Review comment:
In my mind, if a memory manager is associated with a buffer, it should
be safe to assume that that memory manager actually *is* managing that buffer,
i.e. at the very least it should be possible to create a buffer with the same
allocation behavior by calling the associated memory manager's `AllocateBuffer`
method. So, I ended up implementing this special memory manager in the end
because that otherwise wouldn't be the case for these buffers.
In general, I'm too new to the project to have a good understanding of why
there are so many layers of abstractions and methods for creating a buffer and
doing memory management... but surely there *are* good reasons for them, so
wouldn't not implementing them consistently lead to issues down the line?
I will yield to the idea that a lot of this complexity can be removed if
never being able to safely free these buffers is acceptable, because then
they'd just become like any other `Buffer` that has no ownership information
associated with it. But IMO that's a slippery slope at best.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
