Python mutilprocessing Processing 父子進程共享文件對象?
multiprocessing python多進程模塊, 于是, Processing也是多進程的寵兒. 但今天討論的問題, 似乎也能引起我們一番重視
直接上代碼:
frommultiprocessingimportProcess, Lock
err_file = 'error1.log'
err_fd = open(err_file, 'w')
defput(fd):
print "PUT"
fd.write("hello, func put writen")
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中.
那么按理說, 輸出應該如同上面說的那樣, PUT和END,然后error1.log將有那句話”hello, func put write”, 然而, 世事總有那么點難料的, 代碼執行結果是:
[root@iZ23pynfq19Z ~]# py27 2.py ; cat error1.log
PUT
END
[root@iZ23pynfq19Z ~]#
what!? 為什么error1.log沒東西 !?
讓我們稍微調整下代碼, 再見證神奇的事情:
frommultiprocessingimportProcess, Lock
err_file = 'error1.log'
err_fd = open(err_file, 'w')
defput(fd):
print "PUT"
fd.write("hello, func put writen")
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, funcputwrite
o....(有4075個)
[root@iZ23pynfq19Z ~]#
有沒有覺得一種懵逼的感覺!?
如今, 心中涌現兩個問題:
- 為什么第一個程序無法寫入那句話 , 但是第二個卻可以?
- 那個4075是什么鬼?
在解釋這些問題之前, 我們需要清楚標準IO庫所具有的特點: 全緩沖, 行緩沖, 不緩沖
因為現在是寫入文件, 所以系統IO將采用全緩沖的方式, 也就是說, 會將緩沖區填滿才刷入系統寫隊列.
所以上面的問題就一下子全解決了, 正因為那些 迷一般的 ‘o’,填滿了整個緩沖區, 所以系統將我們的內容刷進去寫隊列,所以4075怎么來, 就是用4096-sizeof(“hello, func put writen”)+1, 為什么要+1, 因為緩沖區滿還不行, 要大于才能觸發寫動作.
所以我們現在已經能夠得出答案, 如果我們想要在multiprcessing.Process中, 用上面類似的方式去寫文件時,有三種方法去實現:
- 寫滿緩沖區
- 手動調用flush()
- 將文件對象設置成不緩沖
第一第二種在上面已經闡述, 那我們簡單講下第三種:
取自Python官網Document:
open(name[, mode[, buffering]])
...
Theoptionalbufferingargumentspecifiesthefile’s desiredbuffersize: 0 meansunbuffered,
1 meanslinebuffered, anyotherpositivevaluemeansuse a bufferof (approximately) that
size (in bytes). A negativebufferingmeansto use thesystemdefault, whichis usuallyline
bufferedfor ttydevicesand fullybufferedfor otherfiles. If omitted, thesystemdefault is
used. [2]
上圖說明就是, 允許我們在open的時候, 設置buffering為0, 那么就是unbuffered模式, 那么在每次寫, 就是直接寫入寫隊列,而不是寫到緩沖區.(性能最低的方式)
————————————————我是切割線———————————————-
談論完現象和處理的方法, 我們應該來點深入的;
相信我們曾經試過, 在沒有顯示關閉文件對象或者顯示調用flush時, 文件依舊能夠正常寫入,那么又是怎么一回事呢?
其實,在我們正常關閉程序時, 進程在退出將會為我們做一些”手尾”, 例如關閉打開的文件描述符, 清理臨時文件,清理內存等等.正是因為系統的這種”好習慣”, 所以我們的數據在文件描述符關閉時,就能刷入寫隊列,文件內容也不會丟失.
那么基于這種認識,我們再回首剛才的問題, 在子進程調用put的時候, 理論上在程序退出時, 并沒顯示關閉文件描述符, 所以數據在緩沖區就丟失了.
讓我們在順藤摸瓜,看Process的實現
multiprocessing/Processing.py
defstart(self):
'''
Start child process
'''
assert self._popenis 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._Popenis not None:
Popen = self._Popen
else:
from .forkingimportPopen
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:
importrandom
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/2291453/blog/813259
在上面的鏈接, 我們能夠比較清楚看到 _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:
importrandom
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, funcputwrite
我們可以看到, 確實是可以寫進去, 這樣就證明上面的說法是站得住腳步的
不過最好還是不要亂改源碼哦, 畢竟這些都是老前輩多年優化的結果,可能這是他們故意這些寫,為了避免某些問題.還是規范好自己的行為,盡量減少這些看起來不怎么規范的實現思路吧
來自:http://python.jobbole.com/87360/