Repository navigation
PyType_AddWatcher and friends are not thread safe in free-threading #131544
Description
Activity
I think it may be fine to just document that
PyType_AddWatcher()isn't thread-safe and should be called at start up.I'm pretty sure that Cinder does this already (@mpage ?) and I'm not sure there are any other current users of the API:
so maybe instead of adding atomics or locks it would be better to change them to use stop-the-world pause event.
Hmm, I think that we can use CAS operation at
PyType_AddWatcherand use atomic store operation forPyType_ClearWatcherwill be fine if we consider that PyType_AddWatcher only 8.Is there any concerns to add extra atomic operations for those APIs at free-threading?
If you rely on atomics, you have to use them for every access, so also every read of
interp->type_watchers. This adds a bunch of complexity and I don't think there's a good reason to do it.Reacted by Donghee Na
PyType_AddWatcherandPyType_ClearWatcherare not thread safe as it modifies the interp's type watchers non-atomically.PyType_AddWatcher:cpython/Objects/typeobject.c
Lines 949 to 963 in d3f6063
PyType_ClearWatcher:cpython/Objects/typeobject.c
Lines 980 to 989 in d3f6063
I think adding and removing of type watchers is a rare event so maybe instead of adding atomics or locks it would be better to change them to use stop-the-world pause event.
Linked PRs