-
-
Notifications
You must be signed in to change notification settings - Fork 34.4k
The datetime C API is not thread-safe #141563
Copy link
Copy link
Closed
Labels
3.15new features, bugs and security fixesnew features, bugs and security fixesextension-modulesC modules in the Modules dirC modules in the Modules dirtopic-C-APItopic-free-threadingtopic-subinterpreterstype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Metadata
Metadata
Assignees
Labels
3.15new features, bugs and security fixesnew features, bugs and security fixesextension-modulesC modules in the Modules dirC modules in the Modules dirtopic-C-APItopic-free-threadingtopic-subinterpreterstype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Projects
Status
Done
Status
Done
Bug report
Bug description:
datetimehas a C API that we expose through a global variable. This does not work well under multiple threads. For example, ifPyDateTime_IMPORTfails in one thread while another thread is invoking the datetime C API, then that will setPyDateTimeAPItoNULL, leading toNULLpointer dereferences in the original thread.This global variable also forces us to do some nasty hacks with subinterpreters because it exposes static types. I helped fix this a few months ago by making
_datetimestatic (see this thread), but there are probably other issues that I haven't found yet.I think a bandaid fix would be to make
PyDateTimeAPIa thread-local variable, but I suspect that would break a lot of things, nor would that fix this for subinterpreters. More generally, we could deprecatePyDateTime_IMPORTandPyDateTimeAPIin favor of letting users manage the pointer on their own, but I don't know if we can do this without too many code changes (see #141543 and #83785 for the docs side).cc @pganssle
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
PyDateTime_IMPORTthread-safe #144210