]> git.ipfire.org Git - thirdparty/Python/cpython.git/commitdiff
[3.12] gh-125058: update `_thread` docs regarding interruptibility of `lock.acquire...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Fri, 11 Oct 2024 08:22:34 +0000 (10:22 +0200)
committerGitHub <noreply@github.com>
Fri, 11 Oct 2024 08:22:34 +0000 (08:22 +0000)
gh-125058: update `_thread` docs regarding interruptibility of `lock.acquire()` (GH-125141)
(cherry picked from commit 0135848059162ad81478a7776fec622d68a36524)

Co-authored-by: Jan Kaliszewski <zuo@kaliszewski.net>
Doc/library/_thread.rst

index d82f63834dd2d1d46f87b0a0dcec33c8dc932d61..e5cbff0b1ef4bc3f203197cc2a83f1c1fadc2a0e 100644 (file)
@@ -216,9 +216,11 @@ In addition to these methods, lock objects can also be used via the
 * Calling :func:`sys.exit` or raising the :exc:`SystemExit` exception is
   equivalent to calling :func:`_thread.exit`.
 
-* It is not possible to interrupt the :meth:`~threading.Lock.acquire` method on
-  a lock --- the :exc:`KeyboardInterrupt` exception will happen after the lock
-  has been acquired.
+* It is platform-dependent whether the :meth:`~threading.Lock.acquire` method
+  on a lock can be interrupted (so that the :exc:`KeyboardInterrupt` exception
+  will happen immediately, rather than only after the lock has been acquired or
+  the operation has timed out). It can be interrupted on POSIX, but not on
+  Windows.
 
 * When the main thread exits, it is system defined whether the other threads
   survive.  On most systems, they are killed without executing