"Mark Hammond"
Tim and I have been thrashing around in http://python.org/sf/581232 trying to make time.sleep() interruptible for Windows. This turns out to be quite simple, but has unearthed some questions about thread interactions, and seems to have changed semantics on Linux.
While I understand that the docs make almost no guarantees WRT threads and signals,
Don't go there.
I am wondering what the "most desirable" semantics would be assuming the platform supports it.
Consider a Python program with a main thread + 2 extra threads. The 2 extra threads are both in time.sleep(). When Ctrl+C is pressed, the docs seem to clearly state that only the main thread should see a KeyboardInterrupt. My question is: what should happen to the time.sleep() threads?
It seems that Python 1.5.2 on Linux (as supplied by RedHat) would interrupt the 2 threads with IOError(EINTR). CVS Python currently seems to not interrupt the threads at all, allowing the sleep() to continue the full period. (A time.sleep() in the main thread *is* interrupted in both versions)
Are you saying that your patch changes behaviour, or that behaviour changed somewhere between 1.5.2 and current CVS? Or between 2.2 and current CVS? These lines: /* Mask all signals in the current thread before creating the new * thread. This causes the new thread to start with all signals * blocked. */ sigfillset(&newmask); SET_THREAD_SIGMASK(SIG_BLOCK, &newmask, &oldmask); might have something to do with it. Does anyone know where they come from?
For Windows I can do either. However, the Python 1.5.2 semantics seems to make the most sense to me. Was this change in behaviour post 1.5 intentional? The code does not imply the new behaviour is intented (but the code doesn't imply much at all!)
I'd expect the 1.5.2 semantics, but ...
Test code and results below. All clues welcomed!
Well, the behaviour is probably (pairwise) different on FreeBSD, Darwin and Solaris. "Cheers", M. -- Gullible editorial staff continues to post links to any and all articles that vaguely criticize Linux in any way. -- Reason #4 for quitting slashdot today, from http://www.cs.washington.edu/homes/klee/misc/slashdot.html