6 commits

Author	SHA1	Message	Date
Amaury Forgeot d'Arc	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
Christian Heimes	95016e71ea	Update for threading.local test.	2008-01-19 15:06:09 +00:00
Christian Heimes	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
Collin Winter	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
Jim Fulton	9f556a408b	setUp and tearDown functions are now passed the test object	2004-08-28 14:58:31 +00:00
Jim Fulton	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