From: Georg Brandl Date: Sun, 13 Oct 2013 08:23:27 +0000 (+0200) Subject: Closes #15829: document ThreadError and fix exception raised for releasing unlocked... X-Git-Tag: v2.7.6rc1~38 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=6e5ae97c9513ae72a79d6134cc1d6baeb69d7f7e;p=python Closes #15829: document ThreadError and fix exception raised for releasing unlocked locks. --- diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst index 68eb32ca6b..a24c3858db 100644 --- a/Doc/library/threading.rst +++ b/Doc/library/threading.rst @@ -208,6 +208,13 @@ This module defines the following functions and objects: .. versionadded:: 2.5 + +.. exception:: ThreadError + + Raised for various threading-related errors as described below. Note that + many interfaces use :exc:`RuntimeError` instead of :exc:`ThreadError`. + + Detailed interfaces for the objects are documented below. The design of this module is loosely based on Java's threading model. However, @@ -406,7 +413,7 @@ blocks until a call to :meth:`release` in another thread changes it to unlocked, then the :meth:`acquire` call resets it to locked and returns. The :meth:`release` method should only be called in the locked state; it changes the state to unlocked and returns immediately. If an attempt is made to release an -unlocked lock, a :exc:`RuntimeError` will be raised. +unlocked lock, a :exc:`ThreadError` will be raised. When more than one thread is blocked in :meth:`acquire` waiting for the state to turn to unlocked, only one thread proceeds when a :meth:`release` call resets