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?