summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPetri Lehtinen <petri@digip.org>2011-11-12 21:24:00 +0200
committerPetri Lehtinen <petri@digip.org>2011-11-12 21:24:46 +0200
commitc20224da22db0f6fa069c332d7fb65182ef37979 (patch)
treef7117efa27b53bc3ce4e9f32479419d8528af03f
parentab42abd16096390513c2d1b176d2227e76a4b35a (diff)
parent3a8501e71fbc5a0da4c1f10f1265fd24934f2f7c (diff)
downloadcpython-git-c20224da22db0f6fa069c332d7fb65182ef37979.tar.gz
Merge heads
-rw-r--r--Doc/library/threading.rst19
1 files changed, 10 insertions, 9 deletions
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
index 9544466b10..28a3f8177e 100644
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -573,20 +573,21 @@ needs to wake up one consumer thread.
interface is then used to restore the recursion level when the lock is
reacquired.
- .. method:: notify()
+ .. method:: notify(n=1)
- Wake up a thread waiting on this condition, if any. If the calling thread
- has not acquired the lock when this method is called, a
+ By default, wake up one thread waiting on this condition, if any. If the
+ calling thread has not acquired the lock when this method is called, a
:exc:`RuntimeError` is raised.
- This method wakes up one of the threads waiting for the condition
- variable, if any are waiting; it is a no-op if no threads are waiting.
+ This method wakes up at most *n* of the threads waiting for the condition
+ variable; it is a no-op if no threads are waiting.
- The current implementation wakes up exactly one thread, if any are
- waiting. However, it's not safe to rely on this behavior. A future,
- optimized implementation may occasionally wake up more than one thread.
+ The current implementation wakes up exactly *n* threads, if at least *n*
+ threads are waiting. However, it's not safe to rely on this behavior.
+ A future, optimized implementation may occasionally wake up more than
+ *n* threads.
- Note: the awakened thread does not actually return from its :meth:`wait`
+ Note: an awakened thread does not actually return from its :meth:`wait`
call until it can reacquire the lock. Since :meth:`notify` does not
release the lock, its caller should.