From f14a57cbda01ca84c726e553c27eb74f260149e4 Mon Sep 17 00:00:00 2001 From: Serhiy Storchaka Date: Sun, 19 Jul 2026 19:20:37 +0300 Subject: [PATCH] gh-154139: Document that curses is not thread-safe Whether curses is thread-safe depends on the library and how it was built. The blocking and refresh methods release the GIL, so with a non-reentrant curses, unsynchronized use from several threads can crash. Co-authored-by: Claude Opus 4.8 --- Doc/library/curses.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Doc/library/curses.rst b/Doc/library/curses.rst index 9d0bb239af06df..0881e400f38eff 100644 --- a/Doc/library/curses.rst +++ b/Doc/library/curses.rst @@ -31,6 +31,19 @@ Linux and the BSD variants of Unix. Whenever the documentation mentions a *character string* it can be specified as a Unicode string or a byte string. +.. note:: + + Whether curses may be used from several threads + depends on the underlying library and how it was built. + In many implementations, including the default build of ncurses, + the screen state is shared and not thread-safe; + since the blocking and refresh methods + (such as :meth:`~window.getch` and :meth:`~window.refresh`) + release the :term:`GIL`, + unsynchronized use from several threads can then crash the interpreter. + Serialize the calls, + or wrap them in :meth:`window.use` and :meth:`screen.use`. + .. seealso:: Module :mod:`curses.ascii`