我有几个关于Python线程的问题。
Hide userland threads
)A thread can be flagged as a “daemon thread”. The significance of this flag is that the entire Python program exits when only daemon threads are left.
我的理解是:主线程在所有非守护进程线程终止时终止。
所以,如果“整个python程序在只剩下守护进程线程时退出”,python守护进程线程就不是python程序的一部分了?
Python线程在我知道的所有实现(C Python、PyPy和Jython)中都是使用OS线程实现的。对于每个Python线程,都有一个底层OS线程。
一些操作系统(Linux就是其中之一)在所有运行进程的列表中显示由同一可执行文件启动的所有不同线程。这是操作系统的实现细节,而不是Python的实现细节。在其他一些操作系统上,列出所有进程时可能看不到这些线程。
当最后一个非守护进程线程完成时,进程将终止。此时,所有守护进程线程都将终止。因此,这些线程是进程的一部分,但并不阻止它终止(而常规线程将阻止它)。这是用纯Python实现的。当调用系统
_exit
函数(它将杀死所有线程)时,进程终止;当主线程终止(或调用sys.exit
)时,Python解释器检查是否有另一个非守护进程线程正在运行。如果没有,则调用_exit
,否则等待非守护进程线程完成。守护进程线程标志由
threading
模块在纯Python中实现。加载模块时,将创建一个表示主线程的Thread
对象,并将其_exitfunc
方法注册为atexit
挂钩。此函数的代码为:
当调用
sys.exit
或主线程终止时,Python解释器将调用此函数。当函数返回时,解释器将调用系统_exit
函数。当只有守护进程线程在运行时(如果有的话),函数将终止。当调用
_exit
函数时,操作系统将终止所有进程线程,然后终止进程。在完成所有非守护进程线程之前,Python运行时不会调用_exit
函数。所有线程都是进程的一部分。
你的理解不正确。对于OS,进程由许多线程组成,所有线程都是相等的(除了C运行时在
main
函数的末尾添加对_exit
的调用之外,OS的主线程没有什么特殊之处)。操作系统不知道守护进程线程。这纯粹是一个Python概念。Python解释器使用本机线程来实现Python线程,但必须记住创建的线程列表。并且使用它的
atexit
钩子,它确保_exit
函数仅在最后一个非守护进程线程终止时返回操作系统。当使用“整个Python程序”时,文档指的是整个过程。以下程序有助于理解守护进程线程和普通线程之间的区别:
如果您使用“--use嫒daemon”执行此程序,您将看到该程序将只打印少量的
Working hard
行。如果没有这个标志,程序即使在主线程完成时也不会终止,并且程序将打印Working hard
行,直到它被终止。我不熟悉实现,所以让我们做一个实验:
使用
ps -o cmd,nlwp <pid>
报告的线程数是NUM_THREADS+1
(主线程多一个),因此只要OS工具检测到线程数,它们就应该是OS线程。我尝试了使用cpython和jython,尽管在jython中还有一些其他线程在运行,但是对于我添加的每个额外线程,ps
会将线程计数增加一。我不确定
htop
的行为,但ps
似乎是一致的。我在启动线程之前添加了以下行:
当我执行using-cpython时,程序几乎立即终止,并且使用
ps
找不到进程,所以我的猜测是程序与线程一起终止。在jython中,程序以相同的方式工作(它没有终止),因此可能还有一些来自jvm的其他线程阻止程序终止,或者不支持守护进程线程。注意:我在java1.6.0圮23上使用了Ubuntu 11.10和python 2.7.2+以及jython2.2.1
Python线程实际上是一个解释器实现,因为所谓的全局解释器锁(GIL),即使它在技术上使用os级线程机制。在*nix上,它使用了pthreads,但是GIL有效地使它成为应用程序级线程范例的一个混合障碍。因此,您将在ps/top输出中多次在*nix系统上看到它,但它的行为(性能方面)仍然像软件实现的线程。
不,您只是看到了操作系统的底层线程实现。这种行为被*nix pthread(类似于线程)所公开,甚至我也知道windows确实是这样实现线程的。
当程序关闭时,它也会等待所有线程完成。如果您有线程,这可能会无限延迟退出,那么最好将这些线程标记为“守护进程”,并允许您的程序完成,即使这些线程仍在运行。
一些您可能感兴趣的参考资料:
相关问题 更多 >
编程相关推荐