Mark Dickinson <dicki...@gmail.com> added the comment: I'm seeing this failure too, on a 64-bit build of the trunk on OS X 10.6.1.
If I understand the test, it's setting up a timer that's supposed to run for 0.3 seconds of 'virtual time', signal, and then signal every 0.2 seconds of virtual time thereafter. The test passes after 4 (or is it 3?) signals have been handled, for a total of 0.9 seconds of virtual time. The problem appears to be that the 'for i in xrange(100000000): ...' loop simply isn't long enough for 0.9 seconds of virtual time to even elapse: on my machine, around 0.06 seconds of virtual time appear to have elapsed by the time the loop is finished. When I increase the loop to 'for i in xrange(10**10): ...', the test *eventually* passes. Those 0.9 seconds of virtual time took over 29 minutes of real time, on an otherwise mostly-idle machine. (2.53GHz Core 2 Duo.) When I add some actual work into the xrange loop (computing pow(12345, 67890, 10000001) and throwing away the result) then test_itimer_virtual passes, in a reasonably short amount of time (a second or so). I don't know what the precise definition of virtual time is, or whether there's a defect in the way that Snow Leopard is measuring it. At any rate, I don't think the reported behaviour is a bug in the signal module: the test should be fixed somehow, though (perhaps by adding that pow() call). ---------- nosy: +mark.dickinson versions: +Python 2.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7042> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
