Python: Windows下用multiprocessing的深坑

今天在测试多进程时, 发现了一个问题

测试代码:

#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/lib...

摘抄资料如下:

简单的意思应该是下面这样:

因为Windows缺乏linix那种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无处不在都在挖坑....

欢迎各位大神指点交流, QQ讨论群: 258498217
转载请注明来源: https://segmentfault.com/a/11...