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

Add a missed except * #1057

Merged
merged 1 commit into from
Jun 17, 2022
Merged

Conversation

shwina
Copy link
Contributor

@shwina shwina commented Jun 14, 2022

No description provided.

@shwina shwina requested a review from a team as a code owner June 14, 2022 15:54
@shwina shwina added bug Something isn't working non-breaking Non-breaking change labels Jun 14, 2022
@github-actions github-actions bot added the Python Related to RMM Python API label Jun 14, 2022
@harrism harrism added this to PR-WIP in v22.08 Release via automation Jun 15, 2022
@bdice bdice changed the title Add a missed noexcept * Add a missed except * Jun 15, 2022
Copy link
Contributor

@bdice bdice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. (Also I fixed the title of the PR.)

I discovered while reviewing that except + is for C++ exceptions and except * is for Python exceptions! That was new to me - I hadn't used except * before, only except +.

v22.08 Release automation moved this from PR-WIP to PR-Reviewer approved Jun 15, 2022
@vyasr
Copy link
Contributor

vyasr commented Jun 16, 2022

I discovered while reviewing that except + is for C++ exceptions and except * is for Python exceptions! That was new to me - I hadn't used except * before, only except +.

You can also do things like except 0 as a way to specify that a function will return some error code on exit when an exception occurs (and I think there's also a way to say that "0 may indicate an error", something like except 0?). It's consistent with the way languages without exceptions like C use error codes, and Cython is C inspired :)

@vyasr
Copy link
Contributor

vyasr commented Jun 16, 2022

rerun tests

@@ -344,7 +344,7 @@ cdef void _copy_async(const void* src,
void* dst,
size_t count,
ccudart.cudaMemcpyKind kind,
cuda_stream_view stream) nogil:
cuda_stream_view stream) nogil except *:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is except * compatible with nogil? Or are we holding the GIL when raising that exception

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, John! Should this function even be marked nogil? It clearly needs the GIL to raise the RuntimeError that it does

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it's an interesting question. Was thinking this might be permissible, but maybe only in Cython 3 ( cython/cython#3558 )

Copy link
Member

@jakirkham jakirkham Jun 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suppose there are a few options:

  1. Drop the nogil
  2. Use a with gil block in this function if an error comes up
  3. Return -1 (or the error code) and raise outside this function
  4. ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, I didn't even think about that. I think we should probably not mark the function nogil, but just wrap the cudaMemcpyAsync call in a with nogil block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth noting there is some overhead to releasing the GIL. So if the function is fast, it might not be worth releasing the GIL.

Copy link
Contributor

@bdice bdice Jun 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can leave this as nogil even with the raise?

Oh, and the with gil: is no longer required for the raise since 0.29. It's injected automatically when raise is used in a nogil section.

cython/cython#3558 (comment)

Also confirmed in this Changelog entry from 0.29:

Raising exceptions from nogil code will automatically acquire the GIL, instead of requiring an explicit with gil block.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Bradley! 🙏

Was looking for that text in the docs as I was thinking that might be the case, but only found it in relation to 3.0.0. Missed the changelog entry.

As we already require Cython 0.29 as a minimum, we should be good here.

@jakirkham
Copy link
Member

@gpucibot merge

@rapids-bot rapids-bot bot merged commit f68417a into rapidsai:branch-22.08 Jun 17, 2022
v22.08 Release automation moved this from PR-Reviewer approved to Done Jun 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working non-breaking Non-breaking change Python Related to RMM Python API
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants