Lines Matching refs:meth
89 that can be set to true with the :meth:`~Event.set` method and reset to false
90 with the :meth:`clear` method. The :meth:`wait` method blocks until the flag
136 counter representing the number of :meth:`release` calls minus the number of
137 :meth:`acquire` calls, plus an initial value. The :meth:`acquire` method blocks
176 :meth:`~Thread.run` method is called.
187 :meth:`~Thread.run` method is called.
239 constructor, or by overriding the :meth:`run` method in a subclass. No other
241 other words, *only* override the :meth:`__init__` and :meth:`run` methods of
245 thread's :meth:`start` method. This invokes the :meth:`run` method in a
249 stops being alive when its :meth:`run` method terminates -- either normally, or
250 by raising an unhandled exception. The :meth:`is_alive` method tests whether the
253 Other threads can call a thread's :meth:`join` method. This blocks the calling
254 thread until the thread whose :meth:`join` method is called is terminated.
277 daemonic, and cannot be :meth:`join`\ ed. They are never deleted, since it is
289 *target* is the callable object to be invoked by the :meth:`run` method.
309 object's :meth:`run` method to be invoked in a separate thread of control.
318 You may override this method in a subclass. The standard :meth:`run`
326 thread whose :meth:`join` method is called terminates -- either normally
331 (or fractions thereof). As :meth:`join` always returns ``None``, you must
332 call :meth:`isAlive` after :meth:`join` to decide whether a timeout
333 happened -- if the thread is still alive, the :meth:`join` call timed out.
338 A thread can be :meth:`join`\ ed many times.
340 :meth:`join` raises a :exc:`RuntimeError` if an attempt is made to join
342 :meth:`join` a thread before it has been started and attempts to do so
373 This method returns ``True`` just before the :meth:`run` method starts
374 until just after the :meth:`run` method terminates. The module function
383 or not (False). This must be set before :meth:`start` is called,
410 in the unlocked state. It has two basic methods, :meth:`acquire` and
411 :meth:`release`. When the state is unlocked, :meth:`acquire` changes the state
412 to locked and returns immediately. When the state is locked, :meth:`acquire`
413 blocks until a call to :meth:`release` in another thread changes it to unlocked,
414 then the :meth:`acquire` call resets it to locked and returns. The
415 :meth:`release` method should only be called in the locked state; it changes the
419 When more than one thread is blocked in :meth:`acquire` waiting for the state to
420 turn to unlocked, only one thread proceeds when a :meth:`release` call resets
463 To lock the lock, a thread calls its :meth:`acquire` method; this returns once
465 :meth:`release` method. :meth:`acquire`/:meth:`release` call pairs may be
466 nested; only the final :meth:`release` (the :meth:`release` of the outermost
468 :meth:`acquire` to proceed.
515 A condition variable has :meth:`acquire` and :meth:`release` methods that call
516 the corresponding methods of the associated lock. It also has a :meth:`wait`
517 method, and :meth:`notify` and :meth:`notifyAll` methods. These three must only
521 The :meth:`wait` method releases the lock, and then blocks until it is awakened
522 by a :meth:`notify` or :meth:`notifyAll` call for the same condition variable in
526 The :meth:`notify` method wakes up one of the threads waiting for the condition
527 variable, if any are waiting. The :meth:`notifyAll` method wakes up all threads
530 Note: the :meth:`notify` and :meth:`notifyAll` methods don't release the lock;
532 :meth:`wait` call immediately, but only when the thread that called
533 :meth:`notify` or :meth:`notifyAll` finally relinquishes ownership of the lock.
537 particular change of state call :meth:`wait` repeatedly until they see the
538 desired state, while threads that modify the state call :meth:`notify` or
539 :meth:`notifyAll` when they change the state in such a way that it could
556 To choose between :meth:`notify` and :meth:`notifyAll`, consider whether one
584 awakened by a :meth:`notify` or :meth:`notifyAll` call for the same
593 its :meth:`release` method, since this may not actually unlock the lock
614 Note: an awakened thread does not actually return from its :meth:`wait`
615 call until it can reacquire the lock. Since :meth:`notify` does not
622 :meth:`notify`, but wakes up all waiting threads instead of one. If the
637 used :meth:`P` and :meth:`V` instead of :meth:`acquire` and :meth:`release`).
640 :meth:`acquire` call and incremented by each :meth:`release` call. The counter
641 can never go below zero; when :meth:`acquire` finds that it is zero, it blocks,
642 waiting until some other thread calls :meth:`release`.
658 :meth:`release` to make it larger than zero. This is done with proper
659 interlocking so that if multiple :meth:`acquire` calls are blocked,
660 :meth:`release` will wake exactly one of them up. The implementation may
714 :meth:`~Event.set` method and reset to false with the :meth:`~Event.clear`
715 method. The :meth:`~Event.wait` method blocks until the flag is true.
733 are awakened. Threads that call :meth:`wait` once the flag is true will
739 :meth:`wait` will block until :meth:`.set` is called to set the internal
746 :meth:`.set` to set the flag to true, or until the optional timeout
769 Timers are started, as with threads, by calling their :meth:`~Timer.start`
771 :meth:`~Timer.cancel` method. The interval the timer will wait before
800 All of the objects provided by this module that have :meth:`acquire` and
801 :meth:`release` methods can be used as context managers for a :keyword:`with`
802 statement. The :meth:`acquire` method will be called when the block is entered,
803 and :meth:`release` will be called when the block is exited.