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_ne w_thread(x,())
time.sleep(60)

[Rene Pijlman]

Re: try finally doesn't

Colin Brown:[color=blue]
>When I run this code and then immediately do a Control-C, I do not get the
>'thread' printed?[/color]

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

--
René Pijlman

[Colin Brown]

Re: try finally doesn't

"Rene Pijlman" <reply.in.the.n ewsgroup@my.add ress.is.invalid > wrote in
message news:214asv4cup pifk71are7unbam 170fgregk@4ax.c om...[color=blue]
> Colin Brown:[color=green]
> >When I run this code and then immediately do a Control-C, I do not get[/color][/color]
the[color=blue][color=green]
> >'thread' printed?[/color]
>
> Output buffering. It does when you import sys and add sys.stdout.flus h()
> after the print statement.
>
> --
> René Pijlman[/color]

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.flus h()

thread.start_ne w_thread(x,())
time.sleep(5)

[Diez B. Roggisch]

Re: try finally doesn't

Colin Brown wrote:
[color=blue]
> 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_ne w_thread(x,())
> time.sleep(60)[/color]

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]

Re: try finally doesn't

"Colin Brown" <cbrown@metserv ice.com> writes:
[color=blue]
> "Rene Pijlman" <reply.in.the.n ewsgroup@my.add ress.is.invalid > wrote in
> message news:214asv4cup pifk71are7unbam 170fgregk@4ax.c om...[color=green]
> > Colin Brown:[color=darkred]
> > >When I run this code and then immediately do a Control-C, I do not get[/color][/color]
> the[color=green][color=darkred]
> > >'thread' printed?[/color]
> >
> > Output buffering. It does when you import sys and add sys.stdout.flus h()
> > after the print statement.
> >
> > --
> > René Pijlman[/color]
>
> Also when I run this on Win2K, I get:[/color]

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

What version of Python are you using?

Cheers,
mwh

--
I have gathered a posie of other men's flowers, and nothing but
the thread that binds them is my own. -- Montaigne

[Colin Brown]

Re: try finally doesn't


"Michael Hudson" <mwh@python.net > wrote in message
news:m3zneivwe3 .fsf@pc150.math s.bris.ac.uk...
....[color=blue]
> Oh, if you're on Windows, things are likely to be different.[/color]
....

Sorry! Can't blame Bill for this one. It does the same thing for me under
RedHat Linux also ;-)
[color=blue]
> What version of Python are you using?[/color]

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.[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]
[cbrown@matahari cbrown]$ cat tryfin.py
import thread, time, sys

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

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

[Jeff Epler]

Re: try finally doesn't

The interaction of signals, threads and exiting is pretty minimal in
Python. I think that in this case a KeyboardInterru pt 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_ne w_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.