Commit Graph

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