As nagged by Tim - time.sleep(10000) can not be
interrupted by Ctrl+C on Windows.  Attaching a patch to
fix this.

Logged In: YES 
user_id=14198

Poo - not a thread-safe patch.  I will think about this some
more tomorrow.

Logged In: YES 
user_id=14198

Here we go - a better patch.  This delivers the exact same
multi-threaded semantics as my Linux build.

Re Ctrl+Break - no argument from me - my "if deemed broken"
was meant to imply that!  Win9x Ctrl+Break must be the same
as Win2k - I seemed to recall on Win9x it behaved like a
Ctrl+C.  No 9x even booted to check, and I don't really care
<wink>

FWIW, my test script:
import time, threading, thread

def sleeper():
    try:
        time.sleep(30)
    finally:
        msg = "Thread %d dieing" % (thread.get_ident(),)
        print msg

threads=[]
for i in range(2):
    t=threading.Thread(target=sleeper)
    t.start()
    threads.append(t)
print "sleeping"
try:
    time.sleep(30)
finally:
    print "waiting"
    [t.join for t in threads]
    print "final short sleep"
    time.sleep(2)

Logged In: YES 
user_id=14198

... need uninterrupted sleep <wink>.  Please ignore the
Ctrl+Break comments - I had my bugs mixed up.  Rest is still
valid tho.

Logged In: YES 
user_id=31435

This definitely makes time.sleep() interruptible on Win98, 
but I don't think it's quite there yet.  Playing with it by 
hand, one time I saw

IOError: [Errno 4] Interrupted function call

instead of KeyboardInterrupt when hitting Ctrl+C in an 
interactive shell.  The attached sleeper.py provokes lots of 
those by using threads (hit Ctrl+C within 10 seconds of 
starting it).

Logged In: YES 
user_id=14198

I think we are faced with a timing problem for signals.  As
far as I can tell, this follows the same code path as other
platforms.

* Interrupted sleep detected.
* Errno of EINTR set.
* PyErr_SetFromErrNo handles EINTR as a special case - if
Py_CheckSignals() returns TRUE, it leaves KeyboardInterrupt
current and discards the current exception.

So, what this means is that *one* interrupted thread will
see the KeyboardInterrupt exception and all others will see
OSError(EINTR).

Indeed, this is exactly what I see for Linux - the main
thread sees the KeyboardInterrupt, while all other threads
see OSError(EINTR).

My guess is that the Sleep(1) I added is not long enough -
that on Win9x the signal handler has not yet been called,
therefore all threads see OSError.  Is this possible?

Logged In: YES 
user_id=31435

Well, there's no Sleep on earth long enough to guarantee 
that some other specific thread got a timeslice, so maybe 
that's the best that can be done.

I'm not sure what you mean when you say that the main 
thread sees KeyboardInterrupt on Linux.  In sleeper.py?  I 
expect the main thread to be hung, waiting to acquire a 
lock that will never be released (when a thread in 
sleeper.py is killed via IOError, it never releases its lock, 
and the main thread should hang trying to acquire it).  A 
lock.acquire() shouldn't be interruptible by Ctrl+C, so 
there's a Linux bug here if the main thread isn't hung.

Anyway, that's irrelevant to this patch, so Accepted and 
back to you.  Reformat so that lines don't go beyond 
column 79?  Also please write some Misc/NEWS blurbs for 
the things you checked in today.  Thanks!

Logged In: YES 
user_id=14198

While there is no sleep long enough to guarantee anything,
we could make it more likely <wink>.  How about we add an
order of magnitude, and sleep for 10ms?  There is no way
this could be considered time critical code.
    
I'm a little confused by your statement:
> (when a thread in sleeper.py is killed via IOError, it
never releases its lock, 
> and the main thread should hang trying to acquire it)

threading.py, Thread.__bootstrap(), via __stop() seems to
ensure that the lock is released in the face of
exceptions.  I don't see how a failing thread (IOError or
otherwise) deadlocks when joining on it.


Re Linux etc.  I didn't realize I was using Python 1.5.2!! 
With that version I saw:
sleeping
Thread 2051 dieing
Exception in thread Thread-2:
Traceback (innermost last):
...
  File "delme.py", line 5, in sleeper
    time.sleep(30)
IOError: [Errno 4] Interrupted system call

Thread 1026 dieing
Exception in thread Thread-1:
Traceback (innermost last):
...
  File "delme.py", line 5, in sleeper
    time.sleep(30)
IOError: [Errno 4] Interrupted system call

waiting
Traceback (innermost last):
  File "delme.py", line 17, in ?
    time.sleep(30)
KeyboardInterrupt

However, with CVS Python on Linux, I see this:

sleeping
waiting
Thread 1026 dieing
Thread 2051 dieing
Traceback (most recent call last):
  File "/home/skip/temp/delme.py", line 18, in ?
    time.sleep(30)
KeyboardInterrupt

[Ignore line number differences!]

NOTE: This only happens *after* the thread's sleep() calls
have expired.  ie, Ctrl+C does *not* appear to interrupt
each thread any more, just the main thread.  Further,
neither 1.5.2 nor CVS Python seem to deadlock at exit
regardless of how often I hit Ctrl+C.

sigh - I am not sure what the intent for Linux is any more
:(  So my specific questions:
    
* In the face of this information, is my patch still
reasonable?  Should we clarify the "most desirable"
semantics (assuming the platform is capable) first?
* Should this apparent linux change be brought up?

Logged In: YES 
user_id=31435

Mark, we're running different code.  I'm talking about 
sleeper.py, which I attached to this bug report a few msgs 
back.  See the file attachment whose name is sleeper.py 
<wink>.  It doesn't use threading.py at all, just raw threads 
and raw locks from the thread module.  See that file and 
what I've been talking about will be clear.

About boosting the Sleep() argument, sure, that's 
reasonable.

I don't know anything about Linux quirks.  The design of the 
Windows gimmick here is such that any number of threads 
can wake up in the WaitForSingleObject().  If Linux happens 
to deliver SIGINT only to the main thread, then I suppose 
only the main thread will get KeyboardInterrupt on Linux.  
But I don't know what Linux does -- we'll have to suck a 
Linux geek in fo find out.

Logged In: YES 
user_id=14198

Sorry about the code mixup.

My code is working as intended by me - we just need to
determine if it is working as intended by anyone else <wink>

Running sleeper.py, the main thread sees a
KeyboardInterrupt, and the other threads all see IOError. 
As Tim says, sleeper.py will deadlock in this case, but
KeyboardInterrupt is still pending on the main thread.

Thus, my change makes sleeper.py work exactly as my Linux
1.5.2 build (where each thread is interrupted).  Under CVS
Linux, the other threads sleep()s are never interrupted.

I will take this to python-dev

Logged In: YES 
user_id=14198

Meant to mention: my win98 box shows my original patch (no
Sleep() change) works exactly the same as my 2k box - Ctrl+C
reliably (for 10 attempts <wink>) delivers IOError to the
secondary threads and KeyboardInterrupt to the main thread.

Ironically, for the script I posted to python-dev, python
2.2 on my win98 box works exactly the same as my Linux CVS
version, while my patch makes Windows Python behave like my
Linux Python 1.5.2

does-anyone-really-care? <0.1 wink> ly

Logged In: YES 
user_id=14198

New patch that only interrupts the main thread.  Tim, can
you please approve/comment?

I have Misc/NEWS blurbs ready to go, but included this bug
in the description so will get this sorted first.

Logged In: YES 
user_id=31435

The code looks fine!  I'll try it after it's checked in <wink>.  
(Seriously, it's such a clear change from the last version I'm 
not worried enough to bother.)

Logged In: YES 
user_id=14198

Checking in timemodule.c;
/cvsroot/python/python/dist/src/Modules/timemodule.c,v  <--
 timemodule.c
new revision: 2.129; previous revision: 2.128
done