What version (or hash if on master) of pybind11 are you using?
master
Problem description
There are a few related data races in free threaded Python (3.13t) involving detail::type_info.
The most serious (found by @vfdev-5) is that the std::vector<type_info *> in registered_types_py is populated outside the internals lock, so a thread may incorrectly see an empty vector (or other crashes). Victor has a PR that addresses this race (#5419).
The other data races are because some fields in type_info may be modified after creation:
type_info::implicit_casts: vector is modified when subclasses are defined
type_info::simple_type: field is set to false when a subclass that uses multiple inheritance is defined
Additionally, a few fields are written after the type_info is exposed in registered_types_cpp/registered_types_py -- I think we want to reorder it so that those fields are initialized earlier.
Finally, there are a few fields that I think are mostly okay in typical usage, but I'm not entirely sure:
type_info::implicit_conversions: modified for py::implicitly_convertible<A, B>() on B's type_info.
type_info::direct_conversions: pointed-to vector modified by PYBIND11_NUMPY_DTYPE(type, ...)
type_info::get_buffer/get_buffer_data: modified by def_buffer()
I think these are okay because they're typically invoked when the type is bound, before the type_info is used by other threads.
Reproducible example code
See test case in https://github.com/pybind/pybind11/pull/5419
Is this a regression? Put the last known working version here if it is.
Required prerequisites
What version (or hash if on master) of pybind11 are you using?
master
Problem description
There are a few related data races in free threaded Python (3.13t) involving
detail::type_info
.The most serious (found by @vfdev-5) is that the
std::vector<type_info *>
inregistered_types_py
is populated outside the internals lock, so a thread may incorrectly see an empty vector (or other crashes). Victor has a PR that addresses this race (#5419).The other data races are because some fields in
type_info
may be modified after creation:type_info::implicit_casts
: vector is modified when subclasses are definedtype_info::simple_type
: field is set to false when a subclass that uses multiple inheritance is definedAdditionally, a few fields are written after the
type_info
is exposed inregistered_types_cpp
/registered_types_py
-- I think we want to reorder it so that those fields are initialized earlier.Finally, there are a few fields that I think are mostly okay in typical usage, but I'm not entirely sure:
type_info::implicit_conversions
: modified forpy::implicitly_convertible<A, B>()
onB
'stype_info
.type_info::direct_conversions
: pointed-to vector modified byPYBIND11_NUMPY_DTYPE(type, ...)
type_info::get_buffer/get_buffer_data
: modified bydef_buffer()
I think these are okay because they're typically invoked when the type is bound, before the
type_info
is used by other threads.Reproducible example code
Is this a regression? Put the last known working version here if it is.
Not a regression