This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tupl
Recipients tupl
Date 2014-06-21.15:44:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1403365475.16.0.757881205569.issue21822@psf.upfronthosting.co.za>
In-reply-to
Content
I am attempting to join a thread after a previous join was interrupted by Ctrl-C.

I did not find any warning for this case in threading module docs, so I assume this is legal.

The full test script is attached, but the essential code is:

def work(t):
    sleep(t)

twork = 3; twait = 4
t = Thread(target=work, args=(twork,))
try:
	t.start()
	t.join(twait)  # here I do Ctrl-C
except KeyboardInterrupt:
	pass
t.join()  # this hangs if twork < twait


I can observe the following reproduce sequence:

1. start another thread that sleeps (or works) for T seconds
2. join that thread with timeout longer than T
3. before thread finishes and join returns, hit Ctrl-C to raise KeyboardInterrupt (KI)
4. after T seconds, thread finishes its (Python) code and KI is raised
5. Process Explorer confirms that thread really terminates (looked at .ident())
6. thread still reports .is_alive() == True
7. second attempt to join that thread hangs indefinitely

I tried replacing try-except clause with custom signal handler for SIGINT, as shown in the script. If the handler does not raise an exception, the thread can be normally joined. If it does, however, the behavior is the same as with default handler.

My _guess_ is that the exception prevents some finishing code that puts Thread into proper stopped state after its target completes.

Running Python 3.4.0 on Windows 7 x64
History
Date User Action Args
2014-06-21 15:44:35tuplsetrecipients: + tupl
2014-06-21 15:44:35tuplsetmessageid: <1403365475.16.0.757881205569.issue21822@psf.upfronthosting.co.za>
2014-06-21 15:44:35tupllinkissue21822 messages
2014-06-21 15:44:34tuplcreate