-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Handling of Python element access in free-threading Python #6191
Comments
Another question, somewhat related to this, is what assumptions should be made under |
This. The directive allows us to avoid bounds checks where possible. If we need it for correctness, then we can't avoid it and that's it. |
I think again it's something that we can choose to accept or ignore depending on how we feel (and it doesn't have to be consistent). They're a little different in intent though - the macros aren't really intended to be used by normal users to enable/disable optimizations. They're available so people with an unsupported implementation of Python can attempt to get it working. |
It means that (certain) macros cannot fail, specifically macros like
Both, I'd say. Sometimes we find bugs, sometimes implementations evolve, and then it's helpful for users to be able to disable these macro options to keep their code working.
Pretty much at that level, I agree. It's about allowing optimisations, not enforcing behaviour. |
Describe your issue
#6178 proposes adjusting
__Pyx_GetItemInt_List_Fast
to ignoreboundscheck
for free-threading Python and usePyList_GetItemRef
(which does bounds-checking, but has the advantage that the reference counting is thread-safe).That's probably fine as a short-term solution, but it seems reasonable that users might want to override this themselves for better performance.
There's a few options:
boundscheck(False)
to mean "also don't bother with threadsafe reference counting". That isn't entirely consistent with its meaning since one could easy write something where multiple threads swapped out items from a constant-length list. In this caseboundscheck
should be unnecessary but threadsafe reference counting wouldn't be.boundscheck(False)
forlist
(and maybe other things) on free-threaded Python (what the PR proposes). It looks like we already ignore it for PyPy here too so it's consistent with the idea what it's an optimization hint and not an order.boundscheck(False)
would continue to work correctly on memoryviews etc (which is really it's main use).threadsafe_reference_counting(False)
directive that gives users the option to go back to the "fast path" even on the free-threading build with the understanding that it's their fault when they get it wrong. I think bothboundscheck==False and threadsafe_reference_counting==False
would be needed for the fast path on the free-threading build, butthreadsafe_reference_counting
could be completely ignored on other builds.The text was updated successfully, but these errors were encountered: