Python: mutilprocessing Processing 父子进程共享文件对象问题

multiprocessing python多进程模块, 因而, Processing也是多进程的宠儿. 但今天讨论的问题, 彷佛也能引发咱们一番重视python

直接上代码:bootstrap

from multiprocessing import Process, Lock
err_file = 'error1.log'  
err_fd = open(err_file, 'w')

def put(fd):
     print "PUT"
     fd.write("hello, func put write\n")
     print "END"

if __name__=='__main__':
    p_list=[]
    for i in range(1):
        p_list.append(Process(target=put, args=(err_fd,)))    
    for p in p_list:
        p.start()
    for p in p_list:
        p.join()

上面的代码意图很清晰: 经过multiprocessing.Process派生一个进程, 去执行put函数, put函数的做用也是很清楚, 输出PUT和END, 而且将"hello, func put write" 写到文件error1.log中.segmentfault

那么按理说, 输出应该如同上面说的那样, PUT和END,而后error1.log将有那句话"hello, func put write", 然而, 世事总有那么点难料的, 代码执行结果是:app

[root@iZ23pynfq19Z ~]# py27 2.py ; cat error1.log 
PUT
END
[root@iZ23pynfq19Z ~]#

what!? 为何error1.log没东西 !?dom

让咱们稍微调整下代码, 再见证神奇的事情:函数

from multiprocessing import Process, Lock
err_file = 'error1.log'  
err_fd = open(err_file, 'w')

def put(fd):
     print "PUT"
     fd.write("hello, func put write\n")
     fd.write("o" * 4075) # 神奇的一行
     print "END"

if __name__=='__main__':
    p_list=[]
    for i in range(1):
        p_list.append(Process(target=put, args=(err_fd,)))    for p in p_list:
        p.start()
    for p in p_list:
        p.join()

输出结果:性能

[root@iZ23pynfq19Z ~]# py27 2.py ; cat error1.log 
PUT
END
hello, func put write
o....(有4075个)
[root@iZ23pynfq19Z ~]#

有没有以为一种懵逼的感受!?学习

现在, 心中涌现两个问题:测试

  1. 为何第一个程序没法写入那句话 , 可是第二个却能够?优化

  2. 那个4075是什么鬼?
    在解释这些问题以前, 咱们须要清楚标准IO库所具备的特色: 全缓冲, 行缓冲, 不缓冲

具体能够看以前博文:https://my.oschina.net/u/2291...

由于如今是写入文件, 因此系统IO将采用全缓冲的方式, 也就是说, 会将缓冲区填满才刷入系统写队列.

因此上面的问题就一会儿全解决了, 正由于那些 迷通常的 'o',填满了整个缓冲区, 因此系统将咱们的内容刷进去写队列,因此4075怎么来, 就是用4096-sizeof("hello, func put writen")+1, 为何要+1, 由于缓冲区满还不行, 要大于才能触发写动做.

因此咱们如今已经可以得出答案, 若是咱们想要在multiprcessing.Process中, 用上面相似的方式去写文件时,有三种方法去实现:

  • 写满缓冲区

  • 手动调用flush()

  • 将文件对象设置成不缓冲
    第一第二种在上面已经阐述, 那咱们简单讲下第三种:

取自Python官网Document:
open(name[, mode[, buffering]])
  ...
  The optional buffering argument specifies the file’s desired buffer size: 0 means unbuffered, 
  1 means line buffered, any other positive value means use a buffer of (approximately) that 
  size (in bytes). A negative buffering means to use the system default, which is usually line 
  buffered for tty devices and fully buffered for other files. If omitted, the system default is 
  used. [2]

上图说明就是, 容许咱们在open的时候, 设置buffering为0, 那么就是unbuffered模式, 那么在每次写, 就是直接写入写队列,而不是写到缓冲区.(性能最低的方式)

------------------------------------------------我是切割线----------------------------------------------

谈论完现象和处理的方法, 咱们应该来点深刻的;

相信咱们曾经试过, 在没有显示关闭文件对象或者显示调用flush时, 文件依旧可以正常写入,那么又是怎么一回事呢?

其实,在咱们正常关闭程序时, 进程在退出将会为咱们作一些"手尾", 例如关闭打开的文件描述符, 清理临时文件,清理内存等等.正是由于系统的这种"好习惯", 因此咱们的数据在文件描述符关闭时,就能刷入写队列,文件内容也不会丢失.

那么基于这种认识,咱们再回首刚才的问题, 在子进程调用put的时候, 理论上在程序退出时, 并没显示关闭文件描述符, 因此数据在缓冲区就丢失了.

让咱们在顺藤摸瓜,看Process的实现

multiprocessing/Processing.py
    def start(self):
        '''
        Start child process
        '''
        assert self._popen is None, 'cannot start a process twice'
        assert self._parent_pid == os.getpid(), \
               'can only start a process object created by current process'
        assert not _current_process._daemonic, \
               'daemonic processes are not allowed to have children'
        _cleanup()
        if self._Popen is not None:
            Popen = self._Popen
        else:
            from .forking import Popen
        self._popen = Popen(self)
        _current_process._children.add(self)

再看下Popn是怎么作?

multiprocessing/forking.py
    class Popen(object):

        def __init__(self, process_obj):
            sys.stdout.flush()
            sys.stderr.flush()
            self.returncode = None

            self.pid = os.fork()
            if self.pid == 0:
                if 'random' in sys.modules:
                    import random
                    random.seed()
                code = process_obj._bootstrap()
                sys.stdout.flush()
                sys.stderr.flush()
                os._exit(code)

关键地方就是最后的 os._exit(code), 为何说最关键? 由于这部分的退出, 将决定进程会处理什么"手尾",

os._exit是什么鬼? 其实就是标准库的_eixt, 因而咱们又能简单学习这东西了

https://my.oschina.net/u/2291...

在上面的连接, 咱们可以比较清楚看到 _exit() 和exit() 是比较不一样的两个东西, _exit() 简单暴力, 直接丢弃用户态的内容,进入内核, 而exit()则比较耐心地为咱们清理

那么咱们是否可以假设: 若是Popen的退出不是os._exit() 会是怎样的效果呢?

很幸运的是, sys.exit() 就是咱们先要的exit(), 事不宜迟, 赶忙试下!

multiprocessing/forking.py
    class Popen(object):

        def __init__(self, process_obj):
            sys.stdout.flush()
            sys.stderr.flush()
            self.returncode = None

            self.pid = os.fork()
            if self.pid == 0:
                if 'random' in sys.modules:
                    import random
                    random.seed()
                code = process_obj._bootstrap()
                sys.stdout.flush()
                sys.stderr.flush()
                #os._exit(code)
                sys.exit(code)

测试代码, 返回最原始那个没有'o'填充的版本

[root@iZ23pynfq19Z ~]# python 2.py ; cat error1.log 
PUT
END
hello, func put write

咱们能够看到, 确实是能够写进去, 这样就证实上面的说法是站得住脚步的

不过最好仍是不要乱改源码哦, 毕竟这些都是老前辈多年优化的结果,可能这是他们故意这些写,为了不某些问题.仍是规范好本身的行为,尽可能减小这些看起来不怎么规范的实现思路吧
欢迎各位大神指点交流,转载请注明: https://segmentfault.com/a/11...

相关文章
相关标签/搜索