From: Benjamin Peterson <benjamin@python.org>
Date: Sat, 4 Feb 2012 14:55:52 +0000 (-0500)
Subject: threading primitives now have timeouts
X-Git-Tag: v3.2.3rc1~92
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f51ebf94bb527f66331f92ac00f66f529ded73f0;p=thirdparty%2FPython%2Fcpython.git

threading primitives now have timeouts
---

diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst
index 3d83114f7a23..ebc41f8da9bf 100644
--- a/Doc/library/multiprocessing.rst
+++ b/Doc/library/multiprocessing.rst
@@ -876,14 +876,6 @@ object -- see :ref:`multiprocessing-managers`.
 
 .. note::
 
-   The :meth:`acquire` method of :class:`BoundedSemaphore`, :class:`Lock`,
-   :class:`RLock` and :class:`Semaphore` has a timeout parameter not supported
-   by the equivalents in :mod:`threading`.  The signature is
-   ``acquire(block=True, timeout=None)`` with keyword parameters being
-   acceptable.  If *block* is ``True`` and *timeout* is not ``None`` then it
-   specifies a timeout in seconds.  If *block* is ``False`` then *timeout* is
-   ignored.
-
    On Mac OS X, ``sem_timedwait`` is unsupported, so calling ``acquire()`` with
    a timeout will emulate that function's behavior using a sleeping loop.