-
Notifications
You must be signed in to change notification settings - Fork 58
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
Python bindings to cuFileDriverOpen()
and cuFileDriverClose()
#514
Changes from all commits
6cfefb8
2e4f50e
60c1deb
4e9edc0
e1637d7
edcbe60
032c326
77826ee
b61ebff
2efb02e
f0694be
ee71aac
2fb04a6
51e6805
c55c5af
635ae32
6af4af5
3ca8d14
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,62 @@ | ||
# Copyright (c) 2024, NVIDIA CORPORATION. All rights reserved. | ||
# See file LICENSE for terms. | ||
|
||
import atexit | ||
|
||
from kvikio._lib import cufile_driver # type: ignore | ||
|
||
# TODO: Wrap nicely, maybe as a dataclass? | ||
# <https://github.com/rapidsai/kvikio/issues/526> | ||
DriverProperties = cufile_driver.DriverProperties | ||
madsbk marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
|
||
def driver_open() -> None: | ||
"""Open the cuFile driver | ||
|
||
cuFile accepts multiple calls to `driver_open()`. Only the first call | ||
opens the driver, but every call must have a matching call to | ||
`driver_close()`. | ||
|
||
Normally, it is not required to open and close the cuFile driver since | ||
it is done automatically. | ||
|
||
Raises | ||
------ | ||
RuntimeError | ||
If cuFile isn't available. | ||
""" | ||
return cufile_driver.driver_open() | ||
|
||
|
||
def driver_close() -> None: | ||
"""Close the cuFile driver | ||
|
||
cuFile accepts multiple calls to `driver_open()`. Only the first call | ||
opens the driver, but every call must have a matching call to | ||
`driver_close()`. | ||
|
||
Raises | ||
------ | ||
RuntimeError | ||
If cuFile isn't available. | ||
""" | ||
return cufile_driver.driver_close() | ||
|
||
|
||
def initialize() -> None: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question: Whose job is it to call There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The user for now. If we find a Python example that segfaults because of cuFile's termination issues, we should consider calling it in |
||
"""Open the cuFile driver and close it again at module exit | ||
|
||
Normally, it is not required to open and close the cuFile driver since | ||
it is done automatically. | ||
|
||
Notes | ||
----- | ||
Registers an atexit handler that calls :func:`driver_close`. | ||
|
||
Raises | ||
madsbk marked this conversation as resolved.
Show resolved
Hide resolved
|
||
------ | ||
RuntimeError | ||
If cuFile isn't available. | ||
""" | ||
driver_open() | ||
atexit.register(driver_close) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm well if this can error it seems to invalidate my suggestion to use an atexit handler in the C++... |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
# Copyright (c) 2024, NVIDIA CORPORATION. All rights reserved. | ||
# See file LICENSE for terms. | ||
|
||
import pytest | ||
|
||
import kvikio.cufile_driver | ||
|
||
|
||
@pytest.mark.cufile | ||
def test_open_and_close(): | ||
kvikio.cufile_driver.driver_open() | ||
kvikio.cufile_driver.driver_close() |
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.
Could we explicitly register a
std::atexit
handler? Assuming that the CUDA runtime is doing the same, atexit has ordering guarantees so we'll be pushing our exit handler onto the stack to run before CUDA does its cleanup.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.
No. This is explicitly UB
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.
Do we know how CUDA does its teardown, if not via atexit handlers that have predictable ordering?
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 don't think
std::atexit
has ordering guarantees between multiple shared libraries :/