gh-120198: Stop the world when setting __class__ on free-threaded build

[Fidget-Spinner]

• Issue: Read and write of __class__ in two threads causes crash #120198

[vstinner]

To have a more regular try: ... finally: _PyEval_StartTheWorld() pattern, you can add an int res = -1; variable, replace goto err with goto done, and set res to 0 on success (3 lines above).

[colesbury]

I think @vstinner's suggestion is fine. Or you can refactor the parts that should be in a stop-the-world call into it's own function, like we often do for locks.

Another advantage of moving the body to a separate function is that it makes it more clear what data crosses the stop-the-world boundary -- some data loaded before the stop-the-world call may not be valid after it.

[colesbury]

Let's name this like the other functions: _PyObject_MaterializeManagedDict_LockHeld and move the definition up next to _PyObject_MaterializeManagedDict.

[colesbury]

I think @vstinner's suggestion is fine. Or you can refactor the parts that should be in a stop-the-world call into it's own function, like we often do for locks.

Another advantage of moving the body to a separate function is that it makes it more clear what data crosses the stop-the-world boundary -- some data loaded before the stop-the-world call may not be valid after it.

[colesbury]

LGTM with a few comments about comments.

I think this should be backported to 3.13

[miss-islington-app]

Thanks @Fidget-Spinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @Fidget-Spinner, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 3bfc9c831ad9a3dcf4457e842f1e612e93014a17 3.13