-
Notifications
You must be signed in to change notification settings - Fork 157
Update exchange API to be capsule following new convention #180
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
Conversation
|
cc @Kathryn-cat |
|
RFC thread #179 |
This PR updates the exchange API to be capsule following the new convention. Note that the exchange API python recommendation is not yet updated on the array-api side and so far there hasn't yet been downstream implementation, so this change should be safe in generally.
|
Array api spec PR data-apis/array-api#984 |
|
Sorry for delay, will try to finish my review in a day or two! |
leofang
left a comment
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.
Thanks, @tqchen! LGTM overall, left some questions that we should address before merging.
docs/source/python_spec.rst
Outdated
| direct interaction between the array framework PyObject* and DLPack, | ||
| as a result it is harder to implement the C Exchange API through ctypes (because | ||
| ctypes releases GIL by default and sometimes in non-free-threading environment, | ||
| GIL is needed to interact with the Python C API). |
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.
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.
Hmmm, this flew past me. Honestly, I am not sure what this note is getting at. The mention of the GIL seems wrong either way. I think I said it in the meeting too, but don't quite remember.
"Releasing the GIL" actually should be thought of "releases the thread-state". And that affects both free-threaded and non-free threaded python just the same.
The difference is that with the GIL a Python thread must own the thread state (and thus the GIL).
I would be fine with just dropping the note, because I am not sure which functions this affects how right now.
The interesting point to make is that some functions are expected to be called without the thread-state (GIL) held, so they need to grab it (like the note that we have for the deallocator).
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.
Thanks a lot for the note, updated to replace thread state to GIL
Co-authored-by: Leo Fang <[email protected]>
Co-authored-by: Leo Fang <[email protected]>
|
@leofang please take another look, all comments are addressed |
leofang
left a comment
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.
|
sounds good, we can wait for a few days |
|
Yeah, I don't mind (or very slightly prefer) going towards a capsule. |
|
Seems we are close to merge, planning to merge this in incoming week. but happy to also see comments |
|
Thanks, Tianqi & all! Let's get this in! |
This PR updates the exchange API to be capsule following the new convention. Note that the exchange API python recommendation is not yet updated on the array-api side and so far there hasn't yet been downstream implementation, so this change should be safe in generally.