| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
00181 #
Allow arbitrary timeout for Condition.wait, as reported in
https://bugzilla.redhat.com/show_bug.cgi?id=917709
Upstream doesn't want this: http://bugs.python.org/issue17748
But we have no better solution downstream yet, and since there is
no API breakage, we apply this patch.
Doesn't apply to Python 3, where this is fixed otherwise and works.
|
|
|
|
|
|
| |
Rephrase and clarify that "the entire Python program exits when only daemon threads are left". This matches the documentation at https://docs.python.org/3/library/threading.htmlGH-thread-objects.
(cherry picked from commit bb110cc2ed81447fb48805f31146cf31323a8fc3)
Co-authored-by: mbarkhau <mbarkhau@gmail.com>
|
|
|
|
| |
Patch by Nir Soffer.
|
| |
|
|
|
|
| |
Original patch by Peter Saveliev.
|
|
|
|
| |
AttributeError when sys.stderr is None.
|
| |
|
|
|
|
| |
(grafted from e06edc0c7a4951327f0c95ebeebccba6879a6063)
|
|
|
|
| |
Patch by A. Jesse Jiryu Davis.
|
|
|
|
| |
condition variable. Original patch by Thomas Rachel.
|
| |
|
| |
|
|
|
|
| |
module's active list after a fork().
|
| |
|
|
|
|
| |
condition variables to avoid deadlocks in child processes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87710 | gregory.p.smith | 2011-01-03 13:06:12 -0800 (Mon, 03 Jan 2011) | 4 lines
issue6643 - Two locks held within the threading module on each thread instance
needed to be reinitialized after fork(). Adds tests to confirm that they are
and that a potential deadlock and crasher bug are fixed (platform dependant).
........
This required a bit more fiddling for 2.x as __block and __started are __
private as well as the __started Event's __cond. A new "private"
_reset_internal_locks() method is added to Thread and _Event objects to
address this.
|
|
|
|
|
|
|
|
|
|
|
| |
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87341 | antoine.pitrou | 2010-12-17 18:42:16 +0100 (ven., 17 déc. 2010) | 4 lines
Issue #4188: Avoid creating dummy thread objects when logging operations
from the threading module (with the internal verbose flag activated).
........
|
|
|
|
| |
started once"
|
|
|
|
| |
instance stuck in initial state and present in threading.enumerate().
|
| |
|
|
|
|
|
| |
than those started through `threading.Thread` (for example, using
`thread.start_new_thread()`.
|
|
|
|
| |
which are part of a reference cycle.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Reviewer: Benjamin Peterson
|
|
|
|
| |
Reviewer: Christian Heimes
|
|
|
|
| |
they will still live in 3.0 but it can't hurt
|
| |
|
| |
|
|
|
|
| |
This is new in 2.6 so now need to worry about backwards compatibility :)
|
|
|
|
| |
-3.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
any given threading.Thread object. feature request issue 2871.
|
|
|
|
|
|
|
|
|
|
|
|
| |
sys.settrace
calls threading.currentThread.
The correction somewhat improves the code, but it was close.
Many thanks to the "with" construct, which turns python code into C calls.
I wonder if it is not better to sys.settrace(None) just after
running the __main__ module and before finalization.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Undo the only change that might have unexpected effects.
To be followed.
|
|
|
|
|
|
|
| |
up after it was joined had a traceback pointing to that thread's (deleted)
target attribute, while the test was trying to check that the target was
destroyed. Big thanks to Antoine Pitrou for diagnosing the race and pointing
out sys.exc_clear() to kill the exception early. This fixes issue 2496.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new thread had started. At least on my MacBook Pro, that wound up sleeping for
a full 10ms (probably 1 jiffy). By using an Event instead, we can be absolutely
certain that the thread has started, and return more quickly (217us).
Before:
$ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()'
100 loops, best of 3: 10.3 msec per loop
$ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()'
1000000 loops, best of 3: 0.47 usec per loop
After:
$ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()'
1000 loops, best of 3: 217 usec per loop
$ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()'
1000000 loops, best of 3: 0.86 usec per loop
To be fair, the 10ms isn't CPU time, and other threads including the spawned
one get to run during it. There are also some slightly more complicated ways to
get back the .4us in isAlive() if we want.
|
|
|
|
| |
raises an exception.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class RunSelfFunction(object):
def __init__(self):
self.thread = threading.Thread(target=self._run)
self.thread.start()
def _run(self):
pass
from creating a permanent cycle between the object and the thread by having the
Thread delete its references to the object when it completes.
As an example of the effect of this bug, paramiko.Transport inherits from
Thread to avoid it.
|
| |
|