try finally doesn't

[Colin Brown]

When I run this code and then immediately do a Control-C, I do not get the
'thread' printed?

Colin Brown
PyNZ
-----------------------------------------------------------
import thread, time

def x():
try:
time.sleep(60)
finally:
print 'thread'

thread.start_new_thread(x,())
time.sleep(60)

 

[Rene Pijlman]

Colin Brown:

When I run this code and then immediately do a Control-C, I do not get the
'thread' printed?

Output buffering. It does when you import sys and add sys.stdout.flush()
after the print statement.

 

[Colin Brown]

Colin Brown:

Output buffering. It does when you import sys and add sys.stdout.flush()
after the print statement.

Also when I run this on Win2K, I get:
C:\test>cmd
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\test>python -u t3b.py

C:\test>

-----------------------------------------
import thread, time, sys

def x():
try:
time.sleep(60)
finally:
print 'thread'
sys.stdout.flush()

thread.start_new_thread(x,())
time.sleep(5)

 

[Diez B. Roggisch]

When I run this code and then immediately do a Control-C, I do not get the
'thread' printed?

Colin Brown
PyNZ
-----------------------------------------------------------
import thread, time

def x():
try:
time.sleep(60)
finally:
print 'thread'

thread.start_new_thread(x,())
time.sleep(60)

From the signal docs:

Some care must be taken if both signals and threads are used in the same
program. The fundamental thing to remember in using signals and threads
simultaneously is: always perform signal() operations in the main thread of
execution. Any thread can perform an alarm(), getsignal(), or pause(); only
the main thread can set a new signal handler, and the main thread will be
the only one to receive signals (this is enforced by the Python signal
module, even if the underlying thread implementation supports sending
signals to individual threads). This means that signals can't be used as a
means of inter-thread communication. Use locks instead.

So your thread never gets interrupted.

Regards,

Diez

 

[Michael Hudson]

Also when I run this on Win2K, I get:

Oh, if you're on Windows, things are likely to be different.

What version of Python are you using?

Cheers,
mwh

 

[Colin Brown]

....

Oh, if you're on Windows, things are likely to be different.

....

Sorry! Can't blame Bill for this one. It does the same thing for me under
RedHat Linux also ;-)

What version of Python are you using?

Python 2.3.2

Colin

---------------------------------------------------------------
[cbrown@matahari cbrown]$ python2.3
Python 2.3.2 (#1, Oct 6 2003, 10:07:16)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.[cbrown@matahari cbrown]$ cat tryfin.py
import thread, time, sys

def x():
try:
time.sleep(60)
finally:
print 'thread'
sys.stdout.flush()
sys.stderr.flush()

thread.start_new_thread(x,())
time.sleep(5)
[cbrown@matahari cbrown]$ python2.3 -u tryfin.py
[cbrown@matahari cbrown]$

 

[Jeff Epler]

The interaction of signals, threads and exiting is pretty minimal in
Python. I think that in this case a KeyboardInterrupt is delivered to
the main thread, and when it's uncaught it exits the program, closing
all threads.

Python doesn't even have the capability of delivering an exception to an
arbitrary thread, and that would go double for native code with no GIL.

You'll have to write your code more like this:

exiting = 0
active_threads = 0

def x():
global active_threads
active_threads += 1
for i in range(60):
if exiting:
active_threads -= 1
return
sleep(1)

t = thread.start_new_thread(x, ())

try:
time.sleep(60)
finally:
exiting = 1
while active_threads:
sleep(1)

.... except that you'd want to make active_threads into something that
doesn't suffer from race conditions.

Jeff
PS code untested, and you should consider using the threading module
anyway, if you've decided you must use threads to get the job done.