Bug in threading.Thread.join() ?

[Tim Peters]

[Peter Hansen]
> I'm still trying to understand the behaviour that I'm
> seeing but I'm already pretty sure that it's either
> a bug, or something that would be considered a bug if
> it didn't perhaps avoid even worse behaviour.
>
> Inside the join() method of threading.Thread objects,
> a Condition named self.__block is acquired, and then
> the wait logic is executed.  After the wait() finishes,
> self.__block is released and the method returns.
>
> If you hit Ctrl-C while the join's wait() is occurring,
> you'll raise a KeyboardInterrupt and bypass the
> release() call.
>
> (I'm observing this on Win XP with
> Python 2.4 but have no reason to think it wouldn't
> work the same on other platforms, given the docs
> on signals and such.)

Then you're doing something other than what you described.  Here on
WinXP SP2 w/ Python 2.4c2:

>>> import threading
>>> class T(threading.Thread):
...     def run(self):
...         import time
...         while True:
...             time.sleep(1)
...
>>> t =T()
>>> t.start()
>>> t.join()

I can hit Ctrl+C all day at this point, and nothing (visible) happens.
 That's because it's sitting in self.__block.wait(), which is in turn
sitting in waiter.acquire(), and it's simply not possible for Ctrl+C
to interrupt a mutex acquire.

> If you do this, the thread you were waiting for will never be able
> to complete its cleanup because __bootstrap() calls __stop()
> and that tries to acquire the same Condition object,
> which has never been released.  (I suspect this will
> happen only if its the MainThread that is doing
> the join() call since KeyboardInterrupts only occur
> in the main thread.)
>
> A simple try/finally in join() appears to solve the
> problem, but I'm unsure that this is a good idea,
> partly because I'm a little surprised nobody else has
> found this problem before and I lack confidence that
> I've really found a bug.
> 
> Anyone have thoughts on this?

As above, I don't know what you're doing.  Maybe you're doing a join()
with a timeout too?  In that case, I doubt anyone gave any thought to
what happens if you muck with KeyboardInterrupt too.