Message168578
| Author |
jeremy.kloth |
| Recipients |
chris.jerdonek, georg.brandl, jeremy.kloth, ncoghlan, pitrou, sbt |
| Date |
2012年08月19日.15:26:20 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAGvrs3+vHUii9k=JbkZ38idXkU5ZzVQjtNY5bKobSSuHUUi3yQ@mail.gmail.com> |
| In-reply-to |
<1345387425.52.0.107525352586.issue15526@psf.upfronthosting.co.za> |
| Content |
However #1 is the reason that is bug exists in the first place. The
designer of the test guessed wrong on the "magic value" for the
timeout. There will never be a correct timeout value as it varies
from machine to machine and from workload to workload on a given
machine. For any value that is picked, there exists a scenario where
it will fail.
#2 is certainly a viable work-around and it appears that other tests
(notably the test for fork/exec) do similar so it wouldn't be
unprecedented
#3 is really only useful if other tests need a "wait for process"
helper on Windows.
#4 really just highlights a deficiency with os.startfile() so I'm fine
with deferring that to a feature request for 3.4.
I'll cook up a patch implementing #2 unless anyone else is feeling ambitious. |
|