Martin Panter added the comment: I don’t know much about the concurrent.futures testing, but in general IMO it makes more sense to call thread.join(), or at least @reap_threads, in each individual test case that needs it. If appropriate, you can call join() with a one-second timeout, which should be functionally equivalent to @reap_threads. Leaving a background thread running while you start another test seems like a bad idea; concurrent tests aren’t meant to be run in the same process.
Also, I added a gc_collect() call to the test infrastructure in Issue 27787, which may help avoid problems with spurious “dangling” thread object references. ---------- nosy: +martin.panter _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16968> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
