发布时间:2019-09-05 07:13:05编辑:auto阅读(1829)
笔者某天在测试多进程时, 发现了一个问题
测试代码:
#coding: utf8
from multiprocessing import Process
import os
print('Global_print', os.getpid())
def run_proc(name):
print('Run child process %s (%s)…' % (name, os.getpid()))
if __name__=='__main__':
p = Process(target=run_proc, args=('test',))
print(os.getpid())
p.start()
上述代码不复杂, 肉眼就能猜出八九分: 父进程来执行了首尾的两个 print, 而子进程则只执行 run_proc 。
下面就这针对这一个猜测来验证:
在Linux下:
'Global_print', 14382
14382
Run child process test (14383)…
很符合我们的预期, 因为两次 os.getpid() 得到了一样的结果, 而子进程的那句输出也从侧面验证了另外两句 print 是父进程执行的.
接下来看下 Windows:
What ???...
在测试了 debian/centos 等等 unix/linux 不同发行版和不同 Python 版本, 表现均为一致, 也就是上面 Linux 的输出。
然而,在 Windows下也也是很顽固的和上面的输出不一致。众所周知, Windows 和 Linux 在实现多进程上面是有点区别的..
于是, 感觉应该是 Windows 自身的问题, 在咨询了大佬之后, 得知官网早已有对这块进行说明了:
传送门: https://docs.python.org/2/library/multiprocessing.html?highlight=process#windows
资料说明如下:
简单的意思应该是下面这样:
因为 Windows 缺乏 Linux 那种 fork, 所以它会有一些额外的限制:
而刚才的那个问题, 就是因为没有注意到第三点, 所以导致了意想不到的的副作用, 应该用下面的写法取代上面的不安全写法:
from multiprocessing import Process, freeze_support
def foo():
print 'hello'
if __name__ == '__main__':
freeze_support()
p = Process(target=foo)
p.start()
果然 Windows 无处不在都在挖坑....
作者:Lin_R
原文链接:httpt.cnR1Q19ML
上一篇: python中的@符号的作用
下一篇: CentOS6.5安装python2.7
47863
46424
37314
34760
29332
25990
24945
19967
19564
18050
5806°
6433°
5947°
5975°
7080°
5926°
5963°
6456°
6418°
7798°