<p>考虑到全局解释器锁,Python中的线程有些奇怪。如果不按照eliben的建议使用连接超时和isAlive,您可能无法实现所需的功能。</p>
<p>文档中有两个地方给出了这种情况的原因(可能还有更多)。</p>
<p>第一个:</p>
<p>来自<a href="http://docs.python.org/library/signal.html#module-signal" rel="noreferrer">http://docs.python.org/library/signal.html#module-signal</a>:</p>
<blockquote>
<p>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(), pause(),
setitimer() or getitimer(); 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.</p>
</blockquote>
<p>第二个,来自<a href="http://docs.python.org/library/thread.html#module-thread" rel="noreferrer">http://docs.python.org/library/thread.html#module-thread</a>:</p>
<blockquote>
<p>Threads interact strangely with interrupts: the KeyboardInterrupt exception will be
received by an arbitrary thread. (When the signal module is available, interrupts
always go to the main thread.)</p>
</blockquote>
<p><strong>编辑:</strong>在python bug tracker上有一个关于这个机制的不错的讨论:<a href="http://bugs.python.org/issue1167930" rel="noreferrer">http://bugs.python.org/issue1167930</a>。当然,最后圭多说:“那不太可能消失,所以你只能活着
带着这个。正如您所发现的,指定超时可以解决问题
(差不多)</p>