1ce6136018
fixes issue #1522237 , bad init check in _threading_local
2010-02-22 19:55:22 +00:00
aa98058cc4
use assert[Not]In where appropriate
2010-01-23 23:04:36 +00:00
dbf3b258e7
#6990 : clear threading.local's key only after its thread state is removed:
...
fixes local subclasses leaving old state around after a ref cycle GC which
could be recycled by new locals
2009-09-29 04:32:44 +00:00
5c8da86f3a
convert usage of fail* to assert*
2009-06-30 22:57:08 +00:00
1f40c8a8d7
#Issue3088 in-progress: Race condition with instances of classes derived from threading.local:
...
When a thread touches such an object for the first time, a new thread-local __dict__ is created,
and the __init__ method is run.
But a thread switch can occur here; if the other thread touches the same object, it installs another
__dict__; when the first thread resumes, it updates the dictionary of the second...
This is the deep cause of the failures in test_multiprocessing involving "managers" objects.
Also a 2.5 backport candidate.
2008-06-30 22:42:40 +00:00
95016e71ea
Update for threading.local test.
2008-01-19 15:06:09 +00:00
71a0451f67
Added unit test to verify that threading.local doesn't cause ref leaks. It seems that the thread local storage always keeps the storage of the last stopped thread alive. Can anybody comment on it, please?
2008-01-19 13:46:06 +00:00
c2898c5a67
Standardize on test.test_support.run_unittest() (as opposed to a mix of run_unittest() and run_suite()). Also, add functionality to run_unittest() that admits usage of unittest.TestLoader.loadTestsFromModule().
2007-04-25 17:29:52 +00:00
9f556a408b
setUp and tearDown functions are now passed the test object
2004-08-28 14:58:31 +00:00
d15dc06df0
Implemented thread-local data as proposed on python-dev:
...
http://mail.python.org/pipermail/python-dev/2004-June/045785.html
2004-07-14 19:11:50 +00:00
Jack Diederich
Ezio Melotti
Philip Jenvey
Benjamin Peterson
Amaury Forgeot d'Arc
Christian Heimes
Collin Winter
Jim Fulton