-
-
Notifications
You must be signed in to change notification settings - Fork 34.1k
Description
Bug report
Bug description:
datetime has a C API that we expose through a global variable. This does not work well under multiple threads. For example, if PyDateTime_IMPORT fails in one thread while another thread is invoking the datetime C API, then that will set PyDateTimeAPI to NULL, leading to NULL pointer 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 _datetime static (see this thread), but there are probably other issues that I haven't found yet.
I think a bandaid fix would be to make PyDateTimeAPI a thread-local variable, but I suspect that would break a lot of things, nor would that fix this for subinterpreters. More generally, we could deprecate PyDateTime_IMPORT and PyDateTimeAPI in 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
- gh-141563: make
PyDateTime_IMPORTthread-safe #144210 - gh-141563: Add missing cast to _PyDateTime_IMPORT() #144667
- gh-141563: Don't test datetime.h with the limited C API #144673
- gh-141563: Fix test_cext on Windows #144677
- gh-141563: Fix test_cppext on macOS #144685
- gh-141563: Enable test_cppext internal C API tests on macOS #144711
Metadata
Metadata
Assignees
Labels
Projects
Status
Status