Message273260
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. |
|
Date |
User |
Action |
Args |
2016-08-21 02:50:28 | martin.panter | set | recipients:
+ martin.panter, brett.cannon, ezio.melotti, chris.jerdonek, BreamoreBoy, zach.ware, serhiy.storchaka |
2016-08-21 02:50:28 | martin.panter | set | messageid: <1471747828.65.0.974451092388.issue16968@psf.upfronthosting.co.za> |
2016-08-21 02:50:28 | martin.panter | link | issue16968 messages |
2016-08-21 02:50:28 | martin.panter | create | |
|