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...

相關文章
相關標籤/搜索