zeroshade commented on PR #322: URL: https://github.com/apache/arrow-go/pull/322#issuecomment-2762047057
> I suppose if it makes basic usage of the library simpler, then it makes sense. I think we should caution that for "library" code, it should not be used and retain/release should be used instead. Would make sense to put this into the documentation. Alternatively, we could use a build tag to control whether it uses addcleanup or not? (turn whichever isn't in use into no-ops) > Is there a runtime cost to attaching the cleanup callback? An application that does intend to use retain/release may not want to pay the price if there is one. Yes, there's a runtime cost to attaching the cleanup callback (albeit, AFAIK it's very small). In theory, it would be overall cheaper for the AddCleanup solution vs the repeated calls for Retain and Release. One important caveat to keep in mind (that technically still exists even with the current retain/release paradigm) is that users should never maintain a reference to the `[]byte` from the `Bytes()` method of `memory.Buffer` longer than the scope of the buffer (or call to Release). In the case of a non-go allocator, those bytes could get wiped out from under them when the releasing occurs. It may make sense to utilize the new weak.Ptr in some way for how we expose the byte slices from the buffer. -- 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]
