Python: Windows下用 multiprocessing 的深坑

xxggmmxx

　　笔者某天在测试多进程时, 发现了一个问题
　　测试代码:
　　

#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
　　资料说明如下:

http://i2.运维网.com/images/blog/201808/10/1212ee6d95e3eef0a3144f903102ea4e.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

　　简单的意思应该是下面这样:
　　因为 Windows 缺乏 Linux 那种 fork, 所以它会有一些额外的限制:

• 不管是绑定还是未绑定的方法, 都不要直接作为参数传给 Process 初始化的 target, 相反应该要用普通的函数代替
  
• 子进程在访问全局变量时, 可能会与父进程的值不同。 ( 模块级别的常量没这问题 )
  
• 开启新Python 解析器或者创建新 process 时, 确定主模块能够安全的导入。
  

　　而刚才的那个问题, 就是因为没有注意到第三点, 所以导致了意想不到的的副作用, 应该用下面的写法取代上面的不安全写法:
　　

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

http://i2.运维网.com/images/blog/201808/10/ad12cc388b5a54b70ee76dfd85605904.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=