svn+ssh://pythondev@svn.python.org/python/trunk
........
r78517 | gregory.p.smith | 2010-02-28 10:36:09 -0800 (Sun, 28 Feb 2010) | 3 lines
Issue #7481: When a threading.Thread failed to start it would leave the
instance stuck in initial state and present in threading.enumerate().
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76137 | antoine.pitrou | 2009-11-06 23:34:35 +0100 (ven., 06 nov. 2009) | 4 lines
Issue #7270: Add some dedicated unit tests for multi-thread synchronization
primitives such as Lock, RLock, Condition, Event and Semaphore.
........
r76172 | antoine.pitrou | 2009-11-09 17:00:11 +0100 (lun., 09 nov. 2009) | 5 lines
Issue #7282: Fix a memory leak when an RLock was used in a thread other
than those started through `threading.Thread` (for example, using
`thread.start_new_thread()`.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76117 | antoine.pitrou | 2009-11-05 14:42:29 +0100 (jeu., 05 nov. 2009) | 5 lines
Issue #7264: Fix a possible deadlock when deallocating thread-local objects
which are part of a reference cycle.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70897 | benjamin.peterson | 2009-03-31 16:34:42 -0500 (Tue, 31 Mar 2009) | 1 line
fix Thread.ident when it is the main thread or a dummy thread #5632
........
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.
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.
