[Python-Dev] threads, SIGINT and time.sleep()

[Michael Hudson]

"Mark Hammond" <mhammond@skippinet.com.au> writes:

> 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