gh-117657: TSAN Fix races in PyMember_Get and PyMember_Set, for C extensions

[dpdani]

Fix data races that would only be visible when using C extensions.

This is a follow-up on #119368.

I'm intentionally not testing:

• _Py_T_NONE (deprecated)
• _Py_T_OBJECT (deprecated)
• Py_T_STRING (immutable)
• Py_T_STRING_INPLACE (immutable)

Py_T_CHAR

For some reason Py_T_CHAR is untested also in test_capi.test_structmembers.
In fact, it's not even in the supporting C types, which I'm using for the TSAN tests as well: old api, new api.
I'm wondering if there's a specific reason for this, or if it should be in the test suite instead.

I'm guessing that the TSAN suite should cover the thread-safety of Py_T_CHAR regardless?
Or should we dismiss it for TSAN tests as well?

I've added a new member to the T_CHAR member to the _testcapi module, and the rest of the tests don't seem to break.
I can revert this change if needed.

• Issue: Make TSAN tests pass with the GIL disabled in free-threaded builds #117657

[picnixz]

Quite hard to review since everything looks the same and the functions are not ordered by pairs apparently. I didn't go through everything but I had a question and an observation.

[dpdani]

I'm not exactly sure why test_importlib fails, but I don't want to push a dummy commit just to retry it.

Anyways, the TSAN checks for test_free_threading.test_slots are 🟢

[picnixz]

I'm not exactly sure why test_importlib fails, but I don't want to push a dummy commit just to retry it.

I've relaunched the test manually (I can't relaunch the SSL test though, I don't know why)

[colesbury]

Thanks. I left a few comments below.

How long do the added tests takes to run?

[dpdani]

How long do the added tests takes to run?

./python -m test test_free_threading.test_slots

...
Total duration: 2.3 sec
...

[dpdani]

@colesbury can you take another look?

[colesbury]

This mostly looks good. Please add a char test to test_structmembers.py. I think the implementation in the PR is broken (see inline comment) and it's not caught by any unit test.

It's fine to ping me on PRs like you did here, but please also use GitHub's "re-request review" button (top-right corner, in the reviewers section). It means that the PR shows up in my list of "awaiting reviews".

[dpdani]

Sorry, will do.

[dpdani]

I finally had some time to come back to this.

I guess that moving the stores after error checking does slightly change the externally-visible behavior.
Should we write a news entry?

[colesbury]

LGTM