[ python-Bugs-1171023 ] Thread.join() fails to release Lock on KeyboardInterrupt

[SourceForge.net]

Bugs item #1171023, was opened at 2005-03-26 06:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470

Category: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

----------------------------------------------------------------------

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171023&group_id=5470