打包和mayavi相关的python死锁？

Question

我有一个奇怪的问题，希望有人能解释一下。

我有一段复杂的代码，从一个充满脚本的目录开始，我决定将其重新编写成一个包。此代码更改似乎是一些奇怪死锁出现的触发因素。

下面是对该问题进行规范再现的尝试；失败了，因为此代码按预期运行。实际重现问题可能需要大量代码；但我无法想象在上下文中违规代码 sn-p 有什么不同。

import numpy as np
from scipy.sparse import csr_matrix
from threading import Thread

def dummy():
    print 'this is printed'
    I = np.eye(3)
    print 'all is still fine'
    csr_matrix(I)
    print 'this is never printed; csr_matrix appears to be a trigger for deadlock'
    print np.ones(4)
    print 'same problem; somehow, printing ndarrays is no longer cool either'

thr = Thread(target=dummy)
thr.start()

也许文档中的这个简洁评论是相关的？我不确定我是否完全理解这里所说的内容

http://docs.python.org/2/library/threading#importing-in-threaded-code

首先，除了在主模块中，导入不应该产生产生新线程然后以任何方式等待该线程的副作用。如果生成的线程直接或间接尝试导入模块，则不遵守此限制可能会导致死锁。

一些上下文：我正在使用 python 2.7，numpy 1.8，我尝试从 mayavi/traitsui 线程中生成这个新线程（我不明白为什么它应该是相关的，并且在包结构之前工作正常，但是没问题）。此外，在我生成的线程中有大量 numpy/scipy 代码执行得非常好；它只是打印 ndarrays 并创建稀疏矩阵，到目前为止已被证明是死锁的触发器。

我怀疑与 mayavi 有一些奇怪的交互，因为关闭 mayavi 窗口会导致所有死锁的线程重新开始运行。也许这些特定的语句触发了 python 线程让步给了 mayavi 线程，但它们又不知何故无法再次获得焦点？

非常感谢任何有助于进一步缩小这个谜团的提示！

Answer 1

从您的 cmets 看来，您似乎在某个子模块的顶层启动了 UI 事件循环。这不是一个好主意，因为它会导致文档中提到的完全相同的问题。 import foo 永远不应该启动 UI 事件循环。问题是主线程抓住了导入锁来处理模块的导入。此模块在完成导入之前启动 UI 事件循环。这与等待其他线程完成的情况基本相同；您正在等待 UI 循环完成。如果您的 UI 启动了其他线程，则在其他线程中运行的代码将无法导入任何内容（csr_matrix() 和 ndarray.__repr__() 导入其他模块），因为主线程仍然持有导入锁。