On Fri, Mar 28, 2008 at 11:15 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > On Fri, Mar 28, 2008 at 3:31 AM, <[EMAIL PROTECTED]> wrote:
> > >
> > > Neal> Anything that connects to a remote host is definitely flaky.
> > >
> > > Would it maybe help to set up a dedicated host (or virtual host) to
> serve as
> > > the sole target of all network tests?
> >
> > It would help, but not fix the problem. There will still be transient
> > network issues that come up.
>
> We really need to be able to wrap a timeout around any individual
> test, perhaps throwing a TimeoutException if the timeout is reached,
> and have the ability to regard a TimeoutException as not being a
> "failure".
Something like:
@contextmanager
def timeout(max_time):
def RaiseTimeout(signal, frame):
raise TimeoutException
# Why don't we have a context manager for the next line?
old_alarm = signal.signal(signal.SIGALRM, RaiseTimeout)
try:
signal.alarm(max_time)
try:
yield
finally:
signal.alarm(0)
finally:
signal.signal(signal.SIGALRM, old_alarm)
with appropriate fallbacks for Windows. I may not be poking at
test_support for a bit, so anyone else is welcome to check that in, or
a fixed version of it, whenever they're fixing a timing-out test.
Someone else will have to implement the support in regrtest, although
I wouldn't mind having it treat a timeout as a failure, as long as
it's easier to diagnose than the SIGKILL it currently uses for
timeouts.
--
Namasté,
Jeffrey Yasskin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
