Repository navigation
TListOf{Functions,DataMembers}::fIds might need thread protection #6566
Description
E.g. b1d5b97 improves the situation a bit, but in the end we're still left with many unprotected (threading-wise) accesses to both fIds and its content, i.e. addition / removal of elements might happen asynchronously. There are usages in the wild of direct access to fIds, e.g.
root/bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx
Lines 1902 to 1903 in 407cb58
Metadata
Metadata
Assignees
Type
Projects
- Status
- Status
Activity
wlav commentedon Oct 6, 2020
A priori Python code is protected by the GIL, so this access wouldn't be an issue for threaded code (GIL release is ever only on the actual call into C++, not on any setup code to reach that point). Additionally, this is a workaround for ROOT/meta's buggy handling of enums. Since that is now fixed, this particular workaround is no longer necessary and can simply be removed.
ferdymercury commentedon Sep 18, 2025
@guitargeek I saw you were updating/syncing clingwrapper (#19906), do you think this workaround could be removed as part of your (or a separate) PR and this issue closed? Thanks
guitargeek commentedon May 10, 2026
This issue can be closed after the migration to the CppInterOp-based cppyy, as we don't use ROOT reflection features like
TListOf::{Functions,DataMembers}anymore in cppyy.guitargeek commentedon Oct 5, 2026
Closing after #21261. The direct
fIdsaccess in cppyy's clingwrapper that motivated this issue is gone: PyROOT is now wired to the vendored cppjit stack and no longer usesTListOf::{Functions,DataMembers}internals. Read paths in the meta classes are protected byR__LOCKGUARD(gInterpreterMutex). Mutation paths are only reachable withgInterpreterMutex already held (dictionary load/unload inTClass), so per ROOT's global-interpreter-lock threading model no further protection is planned.