-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
long_from_non_binary_base isn't thread-safe with free threading #130599
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
Comments
The global initialization wasn't thread-safe with free threading or per-interpreter GIL. Use a `_PyOnceFlag` to initialize the entries in a thread-safe manner.
The global initialization wasn't thread-safe with free threading or per-interpreter GIL. Use a `_PyOnceFlag` to initialize the entries in a thread-safe manner.
How about computing and initializing that table at runtime initialization? That can be done in |
I haven't benchmarked the time it takes to compute the table, but I don't want to slow down Python startup, especially when most of the table entries will not be used in most programs. If we don't want to lazily initialize the values, I'd prefer to just precompute and hardcode them. |
They are very fast to compute, takes less than 1 microsecond on my machine. If we hard code the table, it perhaps needs entries for different values of |
This avoids a data race in free-threaded builds due to mutating the statically arrays at runtime. Instead, compute and initialize the constants at runtime initialization.
Avoid a data race in free-threaded builds due to mutating global arrays at runtime. Instead, compute the constants with an external Python script and then define them as static global constant arrays. These constants are used by `long_from_non_binary_base()`.
…-130714) Avoid a data race in free-threaded builds due to mutating global arrays at runtime. Instead, compute the constants with an external Python script and then define them as static global constant arrays. These constants are used by `long_from_non_binary_base()`.
Uh oh!
There was an error while loading. Please reload this page.
Bug report
The
long_from_non_binary_base
function in longobject.c isn't thread-safe with free threading or per-interpreter GIL due to the initialization oflog_base_BASE
,convwidth_base
, andconvmultmax_base
:cpython/Objects/longobject.c
Lines 2835 to 2856 in f963239
There are a few ways we could make this thread-safe:
_PyOnceFlag
Originally reported by @ngoldbaum in #130421
cc @tim-one
Linked PRs
long()
#130714The text was updated successfully, but these errors were encountered: