Message147294
| Author |
pitrou |
| Recipients |
ezio.melotti, jackdied, jcea, neologix, pitrou, terry.reedy, vstinner |
| Date |
2011年11月08日.13:36:24 |
| SpamBayes Score |
5.5993516e-09 |
| Marked as misclassified |
No |
| Message-id |
<1320759108.3386.15.camel@localhost.localdomain> |
| In-reply-to |
<1320757361.84.0.0322344167494.issue11812@psf.upfronthosting.co.za> |
| Content |
> Antoine, the problem with this test is the timeout. We can set an
> arbitrary timeout, but how big is big enough?.
I would say answering this question is your task, since you have access
to that buildbot.
> The only "cosmetic" problem is the risk of "leaking" a thread.
This is not cosmetic, the thread might be keeping all kinds of resources
alive, it might also break other tests which expect there to be a single
running Python thread (if e.g. signals are being tested). We don't want
a failing test to trigger a potential cascade of subsequent failures.
> I could set a timeout of 5 minutes just to satisfy you, but for that
> time the test should have been done yet
The issue is not to satisfy me, it's to satify the buildbots. If you say
that 5 minutes is necessary to reliably resolve "localhost", then surely
there's a configuration problem?
If you say that replacing "localhost" with "127.0.0.1" would fix the
issue, then perhaps we should do that, but we must check that it doesn't
break any other tests (for example IPv6 tests). |
|