thorfour commented on issue #36186: URL: https://github.com/apache/arrow/issues/36186#issuecomment-1601676351
> In terms of the multi-goroutine issue I think that's more of a composition problem for the end user. They could choose to use a separate allocator for each logical array/record creation. Or in our case we have multiple go routines that are building multiple arrays and we want to limit the total usage of that group of go routines so it would make sense for us to limit it with a single allocator. The PR would likely be very large you're right but hopefully it would be relatively straight-forward to review since it would be mostly boiler plate error handling. I'm unfamiliar with any compatibility promises that versions have in this library. I think the breakage by changing the interface by addition would at least be fairly easy for consumers to address in their code since they could just amend their return statements to always return nil thus achieving the same interface they had previously. I'm happy to make the necessary change if this is something that would be accepted. -- 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]
