-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implements an ArrowRootAllocationProvider SPI #1040
base: main
Are you sure you want to change the base?
Conversation
db6c2f1
to
7e9b903
Compare
pom.xml
Outdated
<exclusion> | ||
<groupId>org.checkerframework</groupId> | ||
<artifactId>checker-qual</artifactId> | ||
</exclusion> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not totally certain this is the best way to approach this, but it's a good point for discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is marked outdated because I moved the exclusion to the dependencyManagement
section, but it's still relevant to discuss.
This may need additional work. After doing some brief testing, if someone creates a child allocator from the root allocator, and that child allocator is not properly closed, calling shutdown on the provider seems to raise an IllegalStateException. Changing this to a draft PR in the meantime. |
The latest revision addresses this. |
Other utilities that run within Emissary would benefit from a central source for getting access to an Arrow
RootAllocator
. This PR implements theArrowRootAllocationProvider
that creates a newRootAllocator
and provides a static method for retrieving that instance. It also properly handles callingclose()
on the allocator at shutdown time. It can be initialized by including it in theMETA-INF/service/emissary.spi.InitializationProvider
resource file.In the current state, we leave it up to the consumer to decide whether to create a child allocator using the reference to the root allocator, or to use the root allocator directly. We could decide to force consumers to create child allocators instead of providing references to the root allocator, but I'm not convinced that it is worth doing that at this point.
See also: