mutilprocessingで親プロセスと子プロセス間でファイルオブジェクトを共有する場合の注意点 Pythonでの処理

multiprocessing Python マルチプロセス モジュールなので、Processing もマルチプロセスの最愛の人です。しかし、今日議論された問題は私たちの注目を集めているようです

コードに直接アクセスしてください:

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 を出力し、error1.log に "hello, func put write" を書き込みます。出力が上記の Like、PUT、END のようになっているはずであることは当然です。その後、error1.log には「hello, func put write」という文が含まれますが、状況は常に少し予測不可能で、コードの実行結果は次のようになります:

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

なんと！ ? error1.log に何もないのはなぜですか?質問:

なぜ最初のプログラムはその文を書けないのに、2 番目のプログラムは書けるのでしょうか?

その 4075 とは何ですか? これらの問題を説明する前に、標準 IO を理解する必要があります。ライブラリの機能:

フルバッファリング、ラインバッファリング、バッファリングなし

1. 詳細については、以前のブログ投稿を参照してください: https://my.oschina.net/u/2291...

つまり、システム書き込みキューにフラッシュされる前にバッファがいっぱいになります。

2. したがって、上記の問題はすべて一度に解決されます。バッファ全体がいっぱいなので、システムはコンテンツを書き込みキューにフラッシュします。では、4075 はどのようにして 4096-sizeof("hello, func put writen")+1 を使用するのでしょうか? 1、バッファーがいっぱいで十分ではないため、書き込みアクションをトリガーするには より大きくなければなりません
   これで、multiprocessing.Process で上記と同様の方法でファイルを書き込みたい場合、答えを得ることができます。これを実現するには 3 つの方法があります:

フルバッファを書き込む

手動でフラッシュ()を呼び出す

ファイルオブジェクトをバッファしないように設定する

1つ目と2つ目のタイプについては上で説明したので、簡単に説明しましょう3 番目のタイプについて説明します:

• 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()

上の図 説明は、オープン時にバッファリングを 0 に設定できる、つまりバッファなしモードであるということです。その後、書き込むたびに、書き込むのではなく書き込みキューに直接書き込みます。 (パフォーマンスが最も低い方法)

• --- ------------------------------------ -----------ラインをカット中です ----------------------------------- ------------

話は終わりました 現象と治療方法をさらに深く掘り下げる必要があります;

• ファイルオブジェクトが明示的に閉じられていない場合、またはフラッシュが明示的に呼び出された場合に、それを試したことがあると思います。 、ファイルは引き続き正常に書き込むことができます。それでは何が起こっているのでしょうか?
  

  実際、プログラムを通常どおり閉じると、プロセスは終了後に開いているファイル記述子を閉じたり、クリーニングしたりするなどの「実践的な」作業を行います。一時ファイルの作成、メモリのクリーンアップなど。これはまさにシステムの「習慣」の「良い」性質によるもので、ファイル記述子が閉じられたときにデータが書き込みキューにフラッシュされ、ファイルの内容は消去されません。

それでは、この理解に基づいて、子プロセスが put を呼び出すときの問題を振り返ってみましょう。理論的には、プログラムが終了するとき、ファイル記述子は閉じられていないため、バッファ内のデータは失われます。

手がかりを追って、Process の実装を見てみましょう

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

Popn がどのように行うか見てみましょう

取自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]

重要な場所は最後の os._exit(code) ですが、なぜそれが最も重要なのでしょうか?この部分の内容によって、プロセスがどのような「ハンド」を処理するかが決まります。

os._exit とは何ですか? 実際、これは標準ライブラリの _eixt です。したがって、このことを簡単にもう一度学ぶことができます

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

上記のリンクでは、_exit() と exit() が相対的に 2 つの異なるものであることがはっきりとわかります。_exit() は単純かつ暴力的であり、ユーザー モードを直接破棄しています。コンテンツを削除してカーネルに入る一方で、exit() はより辛抱強くクリーンアップしてくれます

それでは次のように仮定できますか: Popen の exit が os._exit() ではない場合、どのような影響があるでしょうか

幸いなことに、sys.exit()は、最初に必要な exit() です。早速、試してみましょう

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)

コードをテストして、'o' なしで元のコードを返します。実際に記述できることがわかります。上記のステートメントが成り立つことを証明します

しかし、ソースコードを無作為に変更しないのが最善です。結局のところ、これらは長年にわたって先輩によって最適化されているため、結果的に、これはおそらく彼らが特定の問題を回避するために意図的にこれを書いたからです独自の動作を標準化し、これらの一見標準化されていない実装アイデアを減らすように努める方が良いです

転載する際は https と明記してください。

multiprocessing Python マルチプロセス モジュールなので、Processing はマルチプロセスの最愛の人でもありますが、今日議論された問題は私たちの注目を集めているようです

コードに直接:

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)

上記のコードの目的。 put 関数の役割も非常に明確で、PUT と END を出力し、ファイル 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没东西　!?

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

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

我们可以看到, 确实是可以写进去, 这样就证明上面的说法是站得住脚步的

不过最好还是不要乱改源码哦, 毕竟这些都是老前辈多年优化的结果,可能这是他们故意这些写,为了避免某些问题.还是规范好自己的行为,尽量减少这些看起来不怎么规范的实现思路吧

以上がmutilprocessingで親プロセスと子プロセス間でファイルオブジェクトを共有する場合の注意点 Pythonでの処理の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。