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 16:46 Message: Logged In: YES user_id=357491 That was supposed to be bug #1167930, not this bug itself. =) ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
