Skip to content

Fix thread-safety of interpreter cached object str_replace_inf (free threading) #125268

@colesbury

Description

@colesbury

Bug report

We have a number of per-interpreter cached objects. Some of these are lazily initialized in a way that is not thread-safe in the free threading build. (See #125221, for example).

We should go through the remaining ones and make sure they are thread-safe.

EDIT: The only remaining field is str_replace_inf. Accesses to type_slots_pname and type_slots_ptrs are protected by a lock and the TypeVar fields are initialized once early on with other types.

#define _Py_INTERP_CACHED_OBJECT(interp, NAME) \
(interp)->cached_objects.NAME
struct _Py_interp_cached_objects {
PyObject *interned_strings;
/* AST */
PyObject *str_replace_inf;
/* object.__reduce__ */
PyObject *objreduce;
PyObject *type_slots_pname;
pytype_slotdef *type_slots_ptrs[MAX_EQUIV];
/* TypeVar and related types */
PyTypeObject *generic_type;
PyTypeObject *typevar_type;
PyTypeObject *typevartuple_type;
PyTypeObject *paramspec_type;
PyTypeObject *paramspecargs_type;
PyTypeObject *paramspeckwargs_type;
PyTypeObject *constevaluator_type;
};

Linked PRs

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.13bugs and security fixes3.14bugs and security fixestopic-free-threadingtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions