gh-116738: Make cmath module thread-safe

[yoney]

While investigating thread safety in the cmath module, I found that the module is generally thread-safe. However, there is a potential race condition during the initialization of the special value tables in cmath_exec(). This is usually safe, but with subinterpreters, a race condition could occur.

The fix converts all special value tables from runtime initialization to static initialization, eliminating the race condition.

I have also created a test to run under ThreadSanitizer. However, I am not including the test in the current PR because, although this PR addresses the issue in the cmath module, ThreadSanitizer still reports other issues below when subinterpreters and free-threading are used together. I plan to address those issues.

... SUMMARY: ThreadSanitizer: data race /workspace/cmath_tsan/./Modules/posixmodule.c:18691 in posixmodule_exec ... SUMMARY: ThreadSanitizer: data race /workspace/cmath_tsan/Objects/exceptions.c:4547 in _PyBuiltins_AddExceptions ... SUMMARY: ThreadSanitizer: data race /workspace/cmath_tsan/Python/crossinterp_exceptions.h:154 in init_static_exctypes ... ... 

cc: @mpage@colesbury

• Issue: Audit all built-in modules for thread safety #116738

[colesbury]

Generally looks good. It's subinterpreter specific and not really free threading related (i.e., you'll have the same data races with the default GIL enabled build).

[yoney]

Thank you for the review, Sam!

It's subinterpreter specific and not really free threading related.

Yes, I agree, this is related to subinterpreters. I was mainly checking the module for ft-python, which is why I created the PR under gh-116738 to mark it checked.

[skirpichev]

Looks good, but could you double check and verify that all functions include tests for all combinations of special values? I.e. when one component is a zero, infinity or nan, same other (or is a finite nonzero number, if the first is nonzero).

Tests are here: Lib/test/mathdata/cmath_testcases.txt (usually in a dedicated section, like "special values").

Test script

#!/bin/sh# a.sh file=Lib/test/mathdata/cmath_testcases.txt funcs="acos acosh asinh atanh cosh exp log sinh sqrt tanh rect" zeros="0.0 -0.0" nonfinite="-inf nan inf" all="$zeros$nonfinite [1-9]\.[0-9].* -[1-9]\.[0-9].*"forfin$funcsdofort1in$zerosdofort2in$zeros$nonfinitedo re="$f$t1$t2 -> " grep -q "$re"$file||echo"$f$t1$t2 - missing" re="$f$t2$t1 -> " grep -q "$re"$file||echo"$f$t2$t1 - missing"donedonefort1in$nonfinitedofort2in$alldo re="$f$t1$t2 -> " grep -q "$re"$file||echo"$f$t1$t2 - missing!" re="$f$t2$t1 -> " grep -q "$re"$file||echo"$f$t2$t1 - missing!"donedonedone

[skirpichev]

LGTM

I've checked that special values are tested, though appreciate a second look. Please adjust PR description (an maybe title).

[yoney]

I've checked that special values are tested, though appreciate a second look. Please adjust PR description (an maybe title).

Thank you so much, @skirpichev

I’ve checked them as well and they look good to me. I am just sharing how I verified this locally, since it’s easy to accidentally copy-paste something incorrectly and not notice it: I compared the statically initialized version with the previous version before deleting the old tables from the code.

[colesbury]

LGTM

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @colesbury for commit 64254ba 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F142161%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[colesbury]

Buildbot failures are unrelated

[miss-islington-app]

Thanks @yoney for the PR, and @colesbury for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-142261 is a backport of this pull request to the 3.14 branch.