Skip to content
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

[FEA] Expose memory_resource arguments in pylibcudf #15170

Open
wence- opened this issue Feb 28, 2024 · 0 comments
Open

[FEA] Expose memory_resource arguments in pylibcudf #15170

wence- opened this issue Feb 28, 2024 · 0 comments
Assignees
Labels
feature request New feature or request pylibcudf Issues specific to the pylibcudf package

Comments

@wence-
Copy link
Contributor

wence- commented Feb 28, 2024

Is your feature request related to a problem? Please describe.

As discussed in #14229, cudf currently relies on fate (working well so far) to ensure there are no use-after-free bugs when calling into, and taking ownership of return values from, libcudf.

In cudf-classic cython wrappers, the memory resource argument is never exposed to cython land. In pylibcudf, it is not currently exposed either.

Describe the solution you'd like

All pylibcudf calls should take a memory resource argument, that is then called with the memory resource cudf considers to be currently active. This needs to go hand-in-hand with #15163, since when both a stream and memory resource are exposed in the public libcudf API, the memory resource is second, so we can't rely on overloaded defaulting for the stream argument.

Describe alternatives you've considered

None.

@wence- wence- added the feature request New feature or request label Feb 28, 2024
@vyasr vyasr added the pylibcudf Issues specific to the pylibcudf package label May 28, 2024
@Matt711 Matt711 self-assigned this Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request pylibcudf Issues specific to the pylibcudf package
Projects
Status: Todo
Development

No branches or pull requests

3 participants