Author martin.panter
Recipients BreamoreBoy, brett.cannon, chris.jerdonek, ezio.melotti, martin.panter, serhiy.storchaka, zach.ware
Date 2016-08-21.02:50:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1471747828.65.0.974451092388.issue16968@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-08-21 02:50:28martin.pantersetrecipients: + martin.panter, brett.cannon, ezio.melotti, chris.jerdonek, BreamoreBoy, zach.ware, serhiy.storchaka
2016-08-21 02:50:28martin.pantersetmessageid: <1471747828.65.0.974451092388.issue16968@psf.upfronthosting.co.za>
2016-08-21 02:50:28martin.panterlinkissue16968 messages
2016-08-21 02:50:28martin.pantercreate