[EMAIL PROTECTED] > Below are 2 files that isolate the problem. Note, both programs hang > (stop responding)
What does "stop responding" mean? > with hyper-threading turned on (a BIOS setting), but > work as expected with hyper-threading turned off. > > Note, the Windows task manager shows 2 CPUs on the Performance tab with > hyper-threading is turned on. > > Both Python 2.3.5 and 2.4.3 (downloaded from python.org) have this > problem. > The operating system is MS Windows XP Professional. > > winmsd.exe shows: > 2CPUs: x86 Family 15 Model 4 Stepping 1 GenuineIntel ~3000 MHz > Version: 5.1.2600 Service Pack 2 Build 2600 > > Could someone with a hyper-threading (or dual/multicore) CPU please > confirm this bug? I don't see anything unexpected (to me) on a WinXP Pro SP2 box with HT enabled, using 2.4.3, but I'm not sure what "not responding" means to you. > # testsleep.py > import threading > import time > > class Task(threading.Thread): > def __init__(self, n, t): > threading.Thread.__init__(self) > self.n = n > self.t = t > def run(self): > print 'thread %d started' % self.n > print 'sleep time:', self.t > print time.clock() > print time.clock() > print time.clock() > print > count = 0 > printCount = int(10 / self.t) > while True: > start = time.clock() > time.sleep(self.t) > stop = time.clock() > if stop - start > 1.0: > print 'thread', self.n, stop - start You don't _expect_ this print to execute, do you? It should trigger very rarely (if ever). > count += 1 > if count > printCount: > count = 0 > print self.n, > > def test(): > thread1 = Task(1, 0.01) > thread2 = Task(2, 0.003) > thread1.start() > thread2.start() > > test() This is what happened when I ran it, until I got tired of watching it and killed the job: C:\Python24>python test1.py thread 1 started sleep time: 0.01 7.8499538238e-007 4.42770924877e-005 8.62618455186e-005 thread 2 started sleep time: 0.003 0.000479349533238 0.000521904282916 0.000563649037359 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 > # testsleep2.py > import thread > import time > import sys > > def run(n, t): > print 'thread %d started' % n > print 'sleep time:', t > print time.clock() > print time.clock() > print time.clock() > print > count = 0 > printCount = int(10 / t) > while True: > start = time.clock() > time.sleep(t) > stop = time.clock() > if stop - start > 1.0: > print 'thread', n, stop - start See above. > count += 1 > if count > printCount: > count = 0 > print n, > > def test(): > thread.start_new_thread(run, (1, 0.01)) > thread.start_new_thread(run, (2, 0.003)) > > # Wait until the user presses the enter key. > sys.stdin.read(1) Do you want someone running this test to hit the ENTER key, or not? > > test() Works much the same for me, except I got bored quicker ;-): C:\Python24>python test2..py thread 1 started sleep time: 0.01 1.14999323533e-006 8.01271757225e-005 thread 2 started sleep time: 0.003 0.000395865318439 0.000474259857295 0.000559831706872 0.00071061346698 1 2 1 2 1 2 1 2 1 1 2 1 2 1 2 1 2 1 2 1 At that point I hit the ENTER key, and saw: Unhandled exception in thread started by Error in sys.excepthook: Original exception was: Unhandled exception in thread started by Error in sys.excepthook: Original exception was: That's unfortunate, but not unexpected either. The interpreter doesn't wait for a `thread` module thread to finish before tearing itself down, so the threads keep running after Python has torn so much of itself down that weird execptions occur -- and Python is _so_ torn down by that point it can't even display a useful error message. The interpreter does (by default) wait for `threading` module threads to exit before tearing itself down, so those kinds of useless exit messages weren't expected in the first test. -- http://mail.python.org/mailman/listinfo/python-list
