"multiprocessing" --- プロセスベースの並列処理
**********************************************

**ソースコード:** Lib/multiprocessing/

======================================================================

Availability: not Emscripten, not WASI.

This module does not work or is not available on WebAssembly platforms
"wasm32-emscripten" and "wasm32-wasi". See WebAssembly プラットフォー
ム for more information.


はじめに
========

"multiprocessing" is a package that supports spawning processes using
an API similar to the "threading" module.  The "multiprocessing"
package offers both local and remote concurrency, effectively side-
stepping the *Global Interpreter Lock* by using subprocesses instead
of threads.  Due to this, the "multiprocessing" module allows the
programmer to fully leverage multiple processors on a given machine.
It runs on both POSIX and Windows.

"multiprocessing" モジュールでは、"threading" モジュールには似たものが
存在しない API も導入されています。その最たるものが "Pool" オブジェク
トです。これは複数の入力データに対して、サブプロセス群に入力データを分
配 (データ並列) して関数を並列実行するのに便利な手段を提供します。以下
の例では、モジュール内で関数を定義して、子プロセスがそのモジュールを正
常にインポートできるようにする一般的な方法を示します。 "Pool" を用いた
データ並列の基礎的な例は次の通りです:

   from multiprocessing import Pool

   def f(x):
       return x*x

   if __name__ == '__main__':
       with Pool(5) as p:
           print(p.map(f, [1, 2, 3]))

標準出力に以下が出力されます:

   [1, 4, 9]

参考:

  "concurrent.futures.ProcessPoolExecutor" offers a higher level
  interface to push tasks to a background process without blocking
  execution of the calling process. Compared to using the "Pool"
  interface directly, the "concurrent.futures" API more readily allows
  the submission of work to the underlying process pool to be
  separated from waiting for the results.


"Process" クラス
----------------

"multiprocessing" モジュールでは、プロセスは以下の手順によって生成され
ます。はじめに "Process" のオブジェクトを作成し、続いて "start()" メソ
ッドを呼び出します。この "Process" クラスは "threading.Thread" クラス
と同様の API を持っています。まずは、簡単な例をもとにマルチプロセスを
使用したプログラムについてみていきましょう

   from multiprocessing import Process

   def f(name):
       print('hello', name)

   if __name__ == '__main__':
       p = Process(target=f, args=('bob',))
       p.start()
       p.join()

実行された個々のプロセス ID を表示するために拡張したサンプルコードを以
下に示します:

   from multiprocessing import Process
   import os

   def info(title):
       print(title)
       print('module name:', __name__)
       print('parent process:', os.getppid())
       print('process id:', os.getpid())

   def f(name):
       info('function f')
       print('hello', name)

   if __name__ == '__main__':
       info('main line')
       p = Process(target=f, args=('bob',))
       p.start()
       p.join()

なぜ "if __name__ == '__main__'" という記述が必要かは プログラミングガ
イドライン を参照してください。


コンテキストと開始方式
----------------------

プラットフォームにもよりますが、"multiprocessing" はプロセスを開始する
ために 3 つの方法をサポートしています。それら *開始方式* は以下のとお
りです

   *spawn*
      親プロセスは新たに Python インタープリタープロセスを開始します。
      子プロセスはプロセスオブジェクトの "run()" メソッドの実行に必要
      なリソースのみ継承します。特に、親プロセスからの不要なファイル記
      述子とハンドルは継承されません。この方式を使用したプロセスの開始
      は *fork* や *forkserver* に比べ遅くなります。

      Available on POSIX and Windows platforms.  The default on
      Windows and macOS.

   *fork*
      親プロセスは "os.fork()" を使用して Python インタープリターをフ
      ォークします。子プロセスはそれが開始されるとき、事実上親プロセス
      と同一になります。親プロセスのリソースはすべて子プロセスに継承さ
      れます。マルチスレッドプロセスのフォークは安全性に問題があること
      に注意してください。

      Available on POSIX systems.  Currently the default on POSIX
      except macOS.

      注釈:

        The default start method will change away from *fork* in
        Python 3.14. Code that requires *fork* should explicitly
        specify that via "get_context()" or "set_start_method()".

      バージョン 3.12 で変更: If Python is able to detect that your
      process has multiple threads, the "os.fork()" function that this
      start method calls internally will raise a "DeprecationWarning".
      Use a different start method. See the "os.fork()" documentation
      for further explanation.

   *forkserver*
      When the program starts and selects the *forkserver* start
      method, a server process is spawned.  From then on, whenever a
      new process is needed, the parent process connects to the server
      and requests that it fork a new process.  The fork server
      process is single threaded unless system libraries or preloaded
      imports spawn threads as a side-effect so it is generally safe
      for it to use "os.fork()". No unnecessary resources are
      inherited.

      Available on POSIX platforms which support passing file
      descriptors over Unix pipes such as Linux.

バージョン 3.4 で変更: *spawn* added on all POSIX platforms, and
*forkserver* added for some POSIX platforms. Child processes no longer
inherit all of the parents inheritable handles on Windows.

バージョン 3.8 で変更: On macOS, the *spawn* start method is now the
default.  The *fork* start method should be considered unsafe as it
can lead to crashes of the subprocess as macOS system libraries may
start threads. See bpo-33725.

On POSIX using the *spawn* or *forkserver* start methods will also
start a *resource tracker* process which tracks the unlinked named
system resources (such as named semaphores or "SharedMemory" objects)
created by processes of the program.  When all processes have exited
the resource tracker unlinks any remaining tracked object. Usually
there should be none, but if a process was killed by a signal there
may be some "leaked" resources.  (Neither leaked semaphores nor shared
memory segments will be automatically unlinked until the next reboot.
This is problematic for both objects because the system allows only a
limited number of named semaphores, and shared memory segments occupy
some space in the main memory.)

開始方式はメインモジュールの "if __name__ == '__main__'" 節内で、関数
"set_start_method()" によって指定します。以下に例を示します:

   import multiprocessing as mp

   def foo(q):
       q.put('hello')

   if __name__ == '__main__':
       mp.set_start_method('spawn')
       q = mp.Queue()
       p = mp.Process(target=foo, args=(q,))
       p.start()
       print(q.get())
       p.join()

関数 "set_start_method()" はプログラム内で複数回使用してはいけません。

もうひとつの方法として、"get_context()" を使用してコンテキストオブジェ
クトを取得することができます。コンテキストオブジェクトは
multiprocessing モジュールと同じ API を持ち、同じプログラム内で複数の
開始方式を使用できます。

   import multiprocessing as mp

   def foo(q):
       q.put('hello')

   if __name__ == '__main__':
       ctx = mp.get_context('spawn')
       q = ctx.Queue()
       p = ctx.Process(target=foo, args=(q,))
       p.start()
       print(q.get())
       p.join()

あるコンテキストに関連したオブジェクトは、異なるコンテキストのプロセス
とは互換性がない場合があることに注意してください。特に、*fork* コンテ
キストを使用して作成されたロックは、*spawn* あるいは *forkserver* を使
用して開始されたプロセスに渡すことはできません。

特定の開始方式の使用を要求するライブラリは "get_context()" を使用して
ライブラリ利用者の選択を阻害しないようにするべきです。

警告:

  The "'spawn'" and "'forkserver'" start methods generally cannot be
  used with "frozen" executables (i.e., binaries produced by packages
  like **PyInstaller** and **cx_Freeze**) on POSIX systems. The
  "'fork'" start method may work if code does not use threads.


プロセス間でのオブジェクト交換
------------------------------

"multiprocessing" モジュールでは、プロセス間通信の手段が2つ用意されて
います。それぞれ以下に詳細を示します:

**キュー (Queue)**

   "Queue" クラスは "queue.Queue" クラスとほとんど同じように使うことが
   できます。以下に例を示します:

      from multiprocessing import Process, Queue

      def f(q):
          q.put([42, None, 'hello'])

      if __name__ == '__main__':
          q = Queue()
          p = Process(target=f, args=(q,))
          p.start()
          print(q.get())    # prints "[42, None, 'hello']"
          p.join()

   Queues are thread and process safe. Any object put into a
   "multiprocessing" queue will be serialized.

**パイプ (Pipe)**

   "Pipe()" 関数はパイプで繋がれたコネクションオブジェクトのペアを返し
   ます。デフォルトでは双方向性パイプを返します。以下に例を示します:

      from multiprocessing import Process, Pipe

      def f(conn):
          conn.send([42, None, 'hello'])
          conn.close()

      if __name__ == '__main__':
          parent_conn, child_conn = Pipe()
          p = Process(target=f, args=(child_conn,))
          p.start()
          print(parent_conn.recv())   # prints "[42, None, 'hello']"
          p.join()

   パイプのそれぞれの端を表す2つのコネクションオブジェクトが "Pipe()"
   関数から返されます。各コネクションオブジェクトには、 "send()"、
   "recv()"、その他のメソッドがあります。2つのプロセス (またはスレッド
   ) がパイプの *同じ* 端で同時に読み込みや書き込みを行うと、パイプ内
   のデータが破損してしまうかもしれないことに注意してください。もちろ
   ん、各プロセスがパイプの別々の端を同時に使用するならば、データが破
   壊される危険性はありません。

   The "send()" method serializes the the object and "recv()" re-
   creates the object.


プロセス間の同期
----------------

"multiprocessing" は "threading" モジュールと等価な同期プリミティブを
備えています。以下の例では、ロックを使用して、一度に1つのプロセスしか
標準出力に書き込まないようにしています:

   from multiprocessing import Process, Lock

   def f(l, i):
       l.acquire()
       try:
           print('hello world', i)
       finally:
           l.release()

   if __name__ == '__main__':
       lock = Lock()

       for num in range(10):
           Process(target=f, args=(lock, num)).start()

ロックを使用しないで標準出力に書き込んだ場合は、各プロセスからの出力が
ごちゃまぜになってしまいます。


プロセス間での状態の共有
------------------------

これまでの話の流れで触れたとおり、並行プログラミングを行うときには、で
きるかぎり状態を共有しないのが定石です。複数のプロセスを使用するときは
特にそうでしょう。

しかし、どうしてもプロセス間のデータ共有が必要な場合のために
"multiprocessing" モジュールには2つの方法が用意されています。

**共有メモリ (Shared memory)**

   データを共有メモリ上に保持するために "Value" クラス、もしくは
   "Array" クラスを使用することができます。以下のサンプルコードを使っ
   て、この機能についてみていきましょう

      from multiprocessing import Process, Value, Array

      def f(n, a):
          n.value = 3.1415927
          for i in range(len(a)):
              a[i] = -a[i]

      if __name__ == '__main__':
          num = Value('d', 0.0)
          arr = Array('i', range(10))

          p = Process(target=f, args=(num, arr))
          p.start()
          p.join()

          print(num.value)
          print(arr[:])

   このサンプルコードを実行すると以下のように表示されます

      3.1415927
      [0, -1, -2, -3, -4, -5, -6, -7, -8, -9]

   "num" と "arr" を生成するときに使用されている、引数 "'d'" と "'i'"
   は "array" モジュールにより使用される種別の型コードです。ここで使用
   されている "'d'" は倍精度浮動小数、 "'i'" は符号付整数を表します。
   これらの共有オブジェクトは、プロセスセーフでありスレッドセーフです
   。

   共有メモリを使用して、さらに柔軟なプログラミングを行うには
   "multiprocessing.sharedctypes" モジュールを使用します。このモジュー
   ルは共有メモリから割り当てられた任意の ctypes オブジェクトの生成を
   サポートします。

**サーバープロセス (Server process)**

   "Manager()" 関数により生成されたマネージャーオブジェクトはサーバー
   プロセスを管理します。マネージャーオブジェクトは Python のオブジェ
   クトを保持して、他のプロセスがプロキシ経由でその Python オブジェク
   トを操作することができます。

   "Manager()" 関数が返すマネージャは "list", "dict", "Namespace",
   "Lock", "RLock", "Semaphore", "BoundedSemaphore", "Condition",
   "Event", "Barrier", "Queue", "Value", "Array" をサポートします。 以
   下にサンプルコードを示します。

      from multiprocessing import Process, Manager

      def f(d, l):
          d[1] = '1'
          d['2'] = 2
          d[0.25] = None
          l.reverse()

      if __name__ == '__main__':
          with Manager() as manager:
              d = manager.dict()
              l = manager.list(range(10))

              p = Process(target=f, args=(d, l))
              p.start()
              p.join()

              print(d)
              print(l)

   このサンプルコードを実行すると以下のように表示されます

      {0.25: None, 1: '1', '2': 2}
      [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

   サーバープロセスのマネージャーオブジェクトは共有メモリのオブジェク
   トよりも柔軟であるといえます。それは、どのような型のオブジェクトで
   も使えるからです。また、1つのマネージャーオブジェクトはネットワーク
   経由で他のコンピューター上のプロセスによって共有することもできます
   。しかし、共有メモリより動作が遅いという欠点があります。


ワーカープロセスのプールを使用
------------------------------

"Pool" クラスは、ワーカープロセスをプールする機能を備えています。この
クラスには、異なる方法でワーカープロセスへタスクを割り当てるいくつかの
メソッドがあります。

例えば:

   from multiprocessing import Pool, TimeoutError
   import time
   import os

   def f(x):
       return x*x

   if __name__ == '__main__':
       # start 4 worker processes
       with Pool(processes=4) as pool:

           # print "[0, 1, 4,..., 81]"
           print(pool.map(f, range(10)))

           # print same numbers in arbitrary order
           for i in pool.imap_unordered(f, range(10)):
               print(i)

           # evaluate "f(20)" asynchronously
           res = pool.apply_async(f, (20,))      # runs in *only* one process
           print(res.get(timeout=1))             # prints "400"

           # evaluate "os.getpid()" asynchronously
           res = pool.apply_async(os.getpid, ()) # runs in *only* one process
           print(res.get(timeout=1))             # prints the PID of that process

           # launching multiple evaluations asynchronously *may* use more processes
           multiple_results = [pool.apply_async(os.getpid, ()) for i in range(4)]
           print([res.get(timeout=1) for res in multiple_results])

           # make a single worker sleep for 10 seconds
           res = pool.apply_async(time.sleep, (10,))
           try:
               print(res.get(timeout=1))
           except TimeoutError:
               print("We lacked patience and got a multiprocessing.TimeoutError")

           print("For the moment, the pool remains available for more work")

       # exiting the 'with'-block has stopped the pool
       print("Now the pool is closed and no longer available")

プールオブジェクトのメソッドは、そのプールを作成したプロセスのみが呼び
出すべきです。

注釈:

  このパッケージに含まれる機能を使用するためには、子プロセスから
  "__main__" モジュールをインポートできる必要があります。このことにつ
  いては プログラミングガイドライン で触れていますが、ここであらためて
  強調しておきます。なぜかというと、いくつかのサンプルコード、例えば
  "multiprocessing.pool.Pool" のサンプルはインタラクティブシェル上では
  動作しないからです。以下に例を示します:

     >>> from multiprocessing import Pool
     >>> p = Pool(5)
     >>> def f(x):
     ...     return x*x
     ...
     >>> with p:
     ...     p.map(f, [1,2,3])
     Process PoolWorker-1:
     Process PoolWorker-2:
     Process PoolWorker-3:
     Traceback (most recent call last):
     Traceback (most recent call last):
     Traceback (most recent call last):
     AttributeError: Can't get attribute 'f' on <module '__main__' (<class '_frozen_importlib.BuiltinImporter'>)>
     AttributeError: Can't get attribute 'f' on <module '__main__' (<class '_frozen_importlib.BuiltinImporter'>)>
     AttributeError: Can't get attribute 'f' on <module '__main__' (<class '_frozen_importlib.BuiltinImporter'>)>

  (もしこのコードを試すなら、実際には3つの完全なトレースバックがばらば
  らの順番で出力されますし、親プロセスを何らかの方法で止める必要があり
  ます。)


リファレンス
============

"multiprocessing" パッケージは "threading" モジュールの API とほとんど
同じです。


"Process" クラスと例外
----------------------

class multiprocessing.Process(group=None, target=None, name=None, args=(), kwargs={}, *, daemon=None)

   Process オブジェクトは各プロセスの処理を表します。 "Process" クラス
   は "threading.Thread" クラスのすべてのメソッドと同じインターフェー
   スを提供します。

   コンストラクターは必ずキーワード引数で呼び出すべきです。引数
   *group* には必ず "None" を渡してください。 この引数は
   "threading.Thread" クラスとの互換性のためだけに残されています。引数
   *target* には、 "run()" メソッドから呼び出される callable オブジェ
   クトを渡します。この引数はデフォルトで "None" となっており、何も呼
   び出されません。引数 *name* にはプロセス名を渡します (詳細は "name"
   を見てください)。 *args* は対象の呼び出しに対する引数のタプルを渡し
   ます。 *kwargs* は対象の呼び出しに対するキーワード引数の辞書を渡し
   ます。もし提供されれば、キーワード専用の *daemon* 引数はプロセスの
   "daemon" フラグを "True" または "False" にセットします。 "None" の
   場合 (デフォルト)、このフラグは作成するプロセスから継承されます。

   デフォルトでは、*target* に何の引数も与えられません。(実) 引数
   *args* (デフォルトは``()``)は、*target* に渡す引数のリストまたはタ
   プルを指定するために使用されます。

   サブクラスがコンストラクターをオーバーライドする場合は、そのプロセ
   スに対する処理を行う前に基底クラスのコンストラクター
   ("Process.__init__()") を実行しなければなりません。

   バージョン 3.3 で変更: Added the *daemon* parameter.

   run()

      プロセスが実行する処理を表すメソッドです。

      このメソッドはサブクラスでオーバーライドすることができます。標準
      の "run()" メソッドは、コンストラクターの target 引数として渡さ
      れた呼び出し可能オブジェクトを呼び出します。もしコンストラクター
      に *args* もしくは *kwargs* 引数が渡されていれば、呼び出すオブジ
      ェクトにこれらの引数を渡します。

      "Process" に渡される *args* の引数にリストやタプルを使っても、同
      じ効果が得られます。

      以下はプログラム例です:

         >>> from multiprocessing import Process
         >>> p = Process(target=print, args=[1])
         >>> p.run()
         1
         >>> p = Process(target=print, args=(1,))
         >>> p.run()
         1

   start()

      プロセスの処理を開始するためのメソッドです。

      各 Process オブジェクトに対し、このメソッドが2回以上呼び出されて
      はいけません。各プロセスでオブジェクトの "run()" メソッドを呼び
      出す準備を行います。

   join([timeout])

      オプションの引数 *timeout* が "None" (デフォルト) の場合、
      "join()" メソッドが呼ばれたプロセスは処理が終了するまでブロック
      します。 *timeout* が正の数である場合、最大 *timeout* 秒ブロック
      します。 プロセスが終了あるいはタイムアウトした場合、メソッドは
      "None" を返すことに注意してください。 プロセスの "exitcode" を確
      認し終了したかどうかを判断してください。

      1つのプロセスは何回も join されることができます。

      プロセスは自分自身を join することはできません。それはデッドロッ
      クを引き起こすことがあるからです。プロセスが start される前に
      join しようとするとエラーが発生します。

   name

      プロセスの名前。名前は識別のためだけに使用される文字列です。それ
      自体には特別な意味はありません。複数のプロセスに同じ名前が与えら
      れても構いません。

      最初の名前はコンストラクターによってセットされます。コンストラク
      ターに明示的な名前が渡されない場合、 'Process-N_1:N_2:...:N_k'
      形式の名前が構築されます。ここでそれぞれの N_k はその親のN番目の
      子供です。

   is_alive()

      プロセスが実行中かを判別します。

      おおまかに言って、プロセスオブジェクトは "start()" メソッドを呼
      び出してから子プロセス終了までの期間が実行中となります。

   daemon

      デーモンプロセスであるかのフラグであり、ブール値です。この属性は
      "start()" が呼び出される前に設定されている必要があります。

      初期値は作成するプロセスから継承します。

      あるプロセスが終了するとき、そのプロセスはその子プロセスであるデ
      ーモンプロセスすべてを終了させようとします。

      デーモンプロセスは子プロセスを作成できないことに注意してください
      。もし作成できてしまうと、そのデーモンプロセスの親プロセスが終了
      したときにデーモンプロセスの子プロセスが孤児になってしまう場合が
      あるからです。さらに言えば、デーモンプロセスはUnix デーモンやサ
      ービスでは **なく** 通常のプロセスであり、非デーモンプロセスが終
      了すると終了されます (そして join されません)。

   "threading.Thread" クラスの API に加えて "Process" クラスのオブジェ
   クトには以下の属性およびメソッドがあります:

   pid

      プロセスIDを返します。プロセスの生成前は "None" が設定されていま
      す。

   exitcode

      The child's exit code.  This will be "None" if the process has
      not yet terminated.

      If the child's "run()" method returned normally, the exit code
      will be 0.  If it terminated via "sys.exit()" with an integer
      argument *N*, the exit code will be *N*.

      If the child terminated due to an exception not caught within
      "run()", the exit code will be 1.  If it was terminated by
      signal *N*, the exit code will be the negative value *-N*.

   authkey

      プロセスの認証キーです (バイト文字列です)。

      "multiprocessing" モジュールがメインプロセスにより初期化される場
      合には、 "os.urandom()" 関数を使用してランダムな値が設定されます
      。

      "Process" クラスのオブジェクトの作成時にその親プロセスから認証キ
      ーを継承します。もしくは "authkey" に別のバイト文字列を設定する
      こともできます。

      詳細は 認証キー を参照してください。

   sentinel

      プロセスが終了するときに "ready" となるシステムオブジェクトの数
      値ハンドル。

      "multiprocessing.connection.wait()" を使用していくつかのイベント
      を同時に wait したい場合はこの値を使うことができます。それ以外の
      場合は "join()" を呼ぶ方がより単純です。

      On Windows, this is an OS handle usable with the
      "WaitForSingleObject" and "WaitForMultipleObjects" family of API
      calls.  On POSIX, this is a file descriptor usable with
      primitives from the "select" module.

      Added in version 3.3.

   terminate()

      Terminate the process.  On POSIX this is done using the
      "SIGTERM" signal; on Windows "TerminateProcess()" is used.  Note
      that exit handlers and finally clauses, etc., will not be
      executed.

      このメソッドにより終了するプロセスの子孫プロセスは、終了 *しませ
      ん* 。そういった子孫プロセスは単純に孤児になります。

      警告:

        このメソッドの使用時に、関連付けられたプロセスがパイプやキュー
        を使用している場合には、使用中のパイプやキューが破損して他のプ
        ロセスから使用できなくなる可能性があります。同様に、プロセスが
        ロックやセマフォなどを取得している場合には、このプロセスが終了
        してしまうと他のプロセスのデッドロックの原因になるでしょう。

   kill()

      Same as "terminate()" but using the "SIGKILL" signal on POSIX.

      Added in version 3.7.

   close()

      "Process" オブジェクトを閉じ、関連付けられていたすべてのリソース
      を開放します。中のプロセスが実行中であった場合、"ValueError" を
      送出します。"close()" が成功した場合、"Process" オブジェクトの他
      のメソッドや属性は、ほとんどが "ValueError" を送出します。

      Added in version 3.7.

   プロセスオブジェクトが作成したプロセスのみが "start()", "join()",
   "is_alive()", "terminate()" と "exitcode" のメソッドを呼び出すべき
   です。

   以下の例では "Process" のメソッドの使い方を示しています:

      >>> import multiprocessing, time, signal
      >>> mp_context = multiprocessing.get_context('spawn')
      >>> p = mp_context.Process(target=time.sleep, args=(1000,))
      >>> print(p, p.is_alive())
      <...Process ... initial> False
      >>> p.start()
      >>> print(p, p.is_alive())
      <...Process ... started> True
      >>> p.terminate()
      >>> time.sleep(0.1)
      >>> print(p, p.is_alive())
      <...Process ... stopped exitcode=-SIGTERM> False
      >>> p.exitcode == -signal.SIGTERM
      True

exception multiprocessing.ProcessError

   すべての "multiprocessing" 例外の基底クラスです。

exception multiprocessing.BufferTooShort

   この例外は "Connection.recv_bytes_into()" によって発生し、バッファ
   ーオブジェクトが小さすぎてメッセージが読み込めないことを示します。

   "e" が "BufferTooShort" のインスタンスであるとすると、 "e.args[0]"
   はそのメッセージをバイト文字列で与えるものです。

exception multiprocessing.AuthenticationError

   認証エラーがあった場合に送出されます。

exception multiprocessing.TimeoutError

   タイムアウトをサポートするメソッドでタイムアウトが過ぎたときに送出
   されます。


パイプ (Pipe) とキュー (Queue)
------------------------------

複数のプロセスを使う場合、一般的にはメッセージパッシングをプロセス間通
信に使用し、ロックのような同期プリミティブを使用しないようにします。

メッセージのやりとりのために "Pipe()" (2つのプロセス間の通信用)、もし
くはキュー (複数のメッセージ生成プロセス (producer)、消費プロセス
(consumer) の実現用) を使うことができます。

"Queue", "SimpleQueue" と "JoinableQueue" 型は複数プロセスから生成/消
費を行う FIFO (first-in, first-out, 先入れ先出し) キューです。これらの
キューは標準ライブラリの "queue.Queue" を模倣しています。 "Queue" には
Python 2.5 の "queue.Queue" クラスで導入された "task_done()" と
"join()" メソッドがないことが違う点です。

もし "JoinableQueue" を使用するなら、キューから削除される各タスクのた
めに "JoinableQueue.task_done()" を呼び出さなければ **なりません** 。
さもないと、いつか完了していないタスクを数えるためのセマフォがオーバー
フローし、例外を発生させるでしょう。

One difference from other Python queue implementations, is that
"multiprocessing" queues serializes all objects that are put into them
using "pickle". The object return by the get method is a re-created
object that does not share memory with the original object.

管理オブジェクトを使用することで共有キューを作成できることも覚えておい
てください。詳細は マネージャー を参照してください。

注釈:

  "multiprocessing" は、タイムアウトを伝えるために、通常の
  "queue.Empty" と "queue.Full" 例外を使用します。それらは
  "multiprocessing" の名前空間では利用できないため、"queue" からインポ
  ートする必要があります。

注釈:

  オブジェクトがキューに追加される際、そのオブジェクトは pickle 化され
  ています。そのため、バックグラウンドのスレッドが後になって下位層のパ
  イプに pickle 化されたデータをフラッシュすることがあります。これによ
  り、少し驚くような結果になりますが、実際に問題になることはないはずで
  す。これが問題になるような状況では、かわりに manager を使ってキュー
  を作成することができるからです。

  1. 空のキューの中にオブジェクトを追加した後、キューの "empty()" メソ
     ッドが "False" を返すまでの間にごくわずかな遅延が起きることがあり
     、"get_nowait()" が "queue.Empty" を発生させることなく制御が呼び
     出し元に返ってしまうことがあります。

  2. 複数のプロセスがオブジェクトをキューに詰めている場合、キューの反
     対側ではオブジェクトが詰められたのとは違う順序で取得される可能性
     があります。ただし、同一のプロセスから詰め込まれたオブジェクトは
     、それらのオブジェクト間では、必ず期待どおりの順序になります。

警告:

  "Queue" を利用しようとしている最中にプロセスを "Process.terminate()"
  や "os.kill()" で終了させる場合、キューにあるデータは破損し易くなり
  ます。終了した後で他のプロセスがキューを利用しようとすると、例外を発
  生させる可能性があります。

警告:

  上述したように、もし子プロセスがキューへ要素を追加するなら (かつ
  "JoinableQueue.cancel_join_thread" を使用しないなら) そのプロセスは
  バッファーされたすべての要素がパイプへフラッシュされるまで終了しませ
  ん。これは、そのプロセスを join しようとする場合、キューに追加された
  すべての要素が消費されたことが確実でないかぎり、デッドロックを発生さ
  せる可能性があることを意味します。似たような現象で、子プロセスが非デ
  ーモンプロセスの場合、親プロセスは終了時に非デーモンのすべての子プロ
  セスを join しようとしてハングアップする可能性があります。マネージャ
  ーを使用して作成されたキューではこの問題はありません。詳細は プログ
  ラミングガイドライン を参照してください。

プロセス間通信におけるキューの使用例を知りたいなら 使用例 を参照してく
ださい。

multiprocessing.Pipe([duplex])

   パイプの両端を表す "Connection" オブジェクトのペア "(conn1, conn2)"
   を返します。

   *duplex* が "True" (デフォルト) ならパイプは双方向性です。*duplex*
   が "False" ならパイプは一方向性で、"conn1" はメッセージの受信専用、
   "conn2" はメッセージの送信専用になります。

   The "send()" method serializes the the object using "pickle" and
   the "recv()" re-creates the object.

class multiprocessing.Queue([maxsize])

   パイプや2～3個のロック/セマフォを使用して実装されたプロセス共有キュ
   ーを返します。あるプロセスが最初に要素をキューへ追加するとき、バッ
   ファーからパイプの中へオブジェクトを転送する供給スレッドが開始され
   ます。

   標準ライブラリの "queue" モジュールの通常の "queue.Empty" や
   "queue.Full" 例外がタイムアウトを伝えるために送出されます。

   "Queue" は "task_done()" や "join()" を除く "queue.Queue" のすべて
   のメソッドを実装します。

   qsize()

      おおよそのキューのサイズを返します。マルチスレッディング/マルチ
      プロセスの特性上、この数値は信用できません。

      Note that this may raise "NotImplementedError" on platforms like
      macOS where "sem_getvalue()" is not implemented.

   empty()

      キューが空っぽなら "True" を、そうでなければ "False" を返します
      。マルチスレッディング/マルチプロセシングの特性上、これは信用で
      きません。

      May raise an "OSError" on closed queues. (not guaranteed)

   full()

      キューがいっぱいなら "True" を、そうでなければ "False" を返しま
      す。マルチスレッディング/マルチプロセシングの特性上、これは信用
      できません。

   put(obj[, block[, timeout]])

      キューの中へ obj を追加します。オプションの引数 *block* が
      "True" (デフォルト) 且つ *timeout* が "None" (デフォルト) なら、
      空きスロットが利用可能になるまで必要であればブロックします。
      *timeout* が正の数なら、最大 *timeout* 秒ブロックして、その時間
      内に空きスロットが利用できなかったら "queue.Full" 例外を発生させ
      ます。それ以外 (*block* が "False") で、空きスロットがすぐに利用
      可能な場合はキューに要素を追加します。そうでなければ
      "queue.Full" 例外が発生します(その場合 *timeout* は無視されます)
      。

      バージョン 3.8 で変更: If the queue is closed, "ValueError" is
      raised instead of "AssertionError".

   put_nowait(obj)

      "put(obj, False)" と等価です。

   get([block[, timeout]])

      キューから要素を取り出して削除します。オプションの引数 *block*
      が "True" (デフォルト) 且つ *timeout* が "None" (デフォルト) な
      ら、要素が取り出せるまで必要であればブロックします。 *timeout*
      が正の数なら、最大 *timeout* 秒ブロックして、その時間内に要素が
      取り出せなかったら "queue.Empty" 例外を発生させます。それ以外
      (*block* が "False") で、要素がすぐに取り出せる場合は要素を返し
      ます。そうでなければ "queue.Empty" 例外が発生します(その場合
      *timeout* は無視されます)。

      バージョン 3.8 で変更: If the queue is closed, "ValueError" is
      raised instead of "OSError".

   get_nowait()

      "get(False)" と等価です。

   "multiprocessing.Queue" は "queue.Queue" にはない追加メソッドがあり
   ます。 これらのメソッドは通常、ほとんどのコードに必要ありません:

   close()

      カレントプロセスからこのキューへそれ以上データが追加されないこと
      を表します。バックグラウンドスレッドはパイプへバッファーされたす
      べてのデータをフラッシュするとすぐに終了します。これはキューがガ
      ベージコレクトされるときに自動的に呼び出されます。

   join_thread()

      バックグラウンドスレッドを join します。このメソッドは "close()"
      が呼び出された後でのみ使用されます。バッファーされたすべてのデー
      タがパイプへフラッシュされるのを保証するため、バックグラウンドス
      レッドが終了するまでブロックします。

      デフォルトでは、あるプロセスがキューを作成していない場合、終了時
      にキューのバックグラウンドスレッドを join しようとします。そのプ
      ロセスは "join_thread()" が何もしないように
      "cancel_join_thread()" を呼び出すことができます。

   cancel_join_thread()

      "join_thread()" がブロッキングするのを防ぎます。特にこれはバック
      グラウンドスレッドがそのプロセスの終了時に自動的に join されるの
      を防ぎます。詳細は "join_thread()" を参照してください。

      このメソッドは "allow_exit_without_flush()" という名前のほうがよ
      かったかもしれません。キューに追加されたデータが失われてしまいが
      ちなため、このメソッドを使う必要はほぼ確実にないでしょう。本当に
      これが必要になるのは、キューに追加されたデータを下位層のパイプに
      フラッシュすることなくカレントプロセスを直ちに終了する必要があり
      、かつ失われるデータに関心がない場合です。

   注釈:

     このクラスに含まれる機能には、ホストとなるオペレーティングシステ
     ム上で動作している共有セマフォ (shared semaphore) を使用している
     ものがあります。これが使用できない場合には、このクラスが無効にな
     り、 "Queue" をインスタンス化する時に "ImportError" が発生します
     。詳細は bpo-3770 を参照してください。同様のことが、以下に列挙さ
     れている特殊なキューでも成り立ちます。

class multiprocessing.SimpleQueue

   単純化された "Queue" 型です。ロックされた "Pipe" と非常に似ています
   。

   close()

      Close the queue: release internal resources.

      A queue must not be used anymore after it is closed. For
      example, "get()", "put()" and "empty()" methods must no longer
      be called.

      Added in version 3.9.

   empty()

      キューが空ならば "True" を、そうでなければ "False" を返します。

      Always raises an "OSError" if the SimpleQueue is closed.

   get()

      キューから要素を削除して返します。

   put(item)

      *item* をキューに追加します。

class multiprocessing.JoinableQueue([maxsize])

   "JoinableQueue" は "Queue" のサブクラスであり、 "task_done()" や
   "join()" メソッドが追加されているキューです。

   task_done()

      以前にキューへ追加されたタスクが完了したことを表します。キューの
      コンシューマによって使用されます。 タスクをフェッチするために使
      用されるそれぞれの "get()" に対して、 後続の "task_done()" 呼び
      出しはタスクの処理が完了したことをキューへ伝えます。

      もし "join()" がブロッキング状態なら、 すべての要素が処理された
      ときに復帰します( "task_done()" 呼び出しが すべての要素からキュ
      ー内へ "put()" されたと受け取ったことを意味します)。

      キューにある要素より多く呼び出された場合 "ValueError" が発生しま
      す。

   join()

      キューにあるすべてのアイテムが取り出されて処理されるまでブロック
      します。

      キューに要素が追加されると未完了タスク数が増えます。コンシューマ
      がキューの要素が取り出されてすべての処理が完了したことを表す
      "task_done()" を呼び出すと数が減ります。 未完了タスク数がゼロに
      なると "join()" はブロッキングを解除します。


その他
------

multiprocessing.active_children()

   カレントプロセスのすべてのアクティブな子プロセスのリストを返します
   。

   これを呼び出すと "join" してすでに終了しているプロセスには副作用が
   あります。

multiprocessing.cpu_count()

   システムの CPU 数を返します。

   This number is not equivalent to the number of CPUs the current
   process can use.  The number of usable CPUs can be obtained with
   "len(os.sched_getaffinity(0))"

   When the number of CPUs cannot be determined a
   "NotImplementedError" is raised.

   参考: "os.cpu_count()"

multiprocessing.current_process()

   カレントプロセスに対応する "Process" オブジェクトを返します。

   "threading.current_thread()" とよく似た関数です。

multiprocessing.parent_process()

   Return the "Process" object corresponding to the parent process of
   the "current_process()". For the main process, "parent_process"
   will be "None".

   Added in version 3.8.

multiprocessing.freeze_support()

   "multiprocessing" を使用しているプログラムをフリーズして Windows の
   実行可能形式を生成するためのサポートを追加します。(**py2exe** ,
   **PyInstaller** や **cx_Freeze** でテストされています。)

   メインモジュールの "if __name__ == '__main__'" の直後にこの関数を呼
   び出す必要があります。以下に例を示します:

      from multiprocessing import Process, freeze_support

      def f():
          print('hello world!')

      if __name__ == '__main__':
          freeze_support()
          Process(target=f).start()

   もし "freeze_support()" の行がない場合、フリーズされた実行可能形式
   を実行しようとすると "RuntimeError" を発生させます。

   "freeze_support()" の呼び出しは Windows 以外の OS では効果がありま
   せん。さらに、もしモジュールが Windows の通常の Python インタプリタ
   によって実行されているならば（プログラムがフリーズされていなければ
   ） "freeze_support()" は効果がありません。

multiprocessing.get_all_start_methods()

   Returns a list of the supported start methods, the first of which
   is the default.  The possible start methods are "'fork'", "'spawn'"
   and "'forkserver'".  Not all platforms support all methods.  See コ
   ンテキストと開始方式.

   Added in version 3.4.

multiprocessing.get_context(method=None)

   "multiprocessing" モジュールと同じ属性を持つコンテキストオブジェク
   トを返します。

   If *method* is "None" then the default context is returned.
   Otherwise *method* should be "'fork'", "'spawn'", "'forkserver'".
   "ValueError" is raised if the specified start method is not
   available.  See コンテキストと開始方式.

   Added in version 3.4.

multiprocessing.get_start_method(allow_none=False)

   開始するプロセスで使用する開始方式名を返します。

   開始方式がまだ確定しておらず、*allow_none* の値が偽の場合、開始方式
   はデフォルトに確定され、その名前が返されます。開始方式が確定してお
   らず、*allow_none* の値が真の場合、 "None" が返されます。

   The return value can be "'fork'", "'spawn'", "'forkserver'" or
   "None".  See コンテキストと開始方式.

   Added in version 3.4.

   バージョン 3.8 で変更: macOS では、 *spawn* 開始方式がデフォルトに
   なりました。 *fork* 開始方法は、サブプロセスのクラッシュを引き起こ
   す可能性があるため、安全ではありません。 bpo-33725 を参照。

multiprocessing.set_executable(executable)

   子プロセスを開始するときに、使用する Python インタープリターのパス
   を設定します。(デフォルトでは "sys.executable" が使用されます)。コ
   ードに組み込むときは、おそらく次のようにする必要があります

      set_executable(os.path.join(sys.exec_prefix, 'pythonw.exe'))

   子プロセスを作成する前に行ってください。

   バージョン 3.4 で変更: Now supported on POSIX when the "'spawn'"
   start method is used.

   バージョン 3.11 で変更: *path-like object* を受け入れるようになりま
   した。

multiprocessing.set_forkserver_preload(module_names)

   Set a list of module names for the forkserver main process to
   attempt to import so that their already imported state is inherited
   by forked processes. Any "ImportError" when doing so is silently
   ignored. This can be used as a performance enhancement to avoid
   repeated work in every process.

   For this to work, it must be called before the forkserver process
   has been launched (before creating a "Pool" or starting a
   "Process").

   Only meaningful when using the "'forkserver'" start method. See コ
   ンテキストと開始方式.

   Added in version 3.4.

multiprocessing.set_start_method(method, force=False)

   Set the method which should be used to start child processes. The
   *method* argument can be "'fork'", "'spawn'" or "'forkserver'".
   Raises "RuntimeError" if the start method has already been set and
   *force* is not "True".  If *method* is "None" and *force* is "True"
   then the start method is set to "None".  If *method* is "None" and
   *force* is "False" then the context is set to the default context.

   これは一度しか呼び出すことができず、その場所もメインモジュールの
   "if __name__ == '__main__'" 節内で保護された状態でなければなりませ
   ん。

   See コンテキストと開始方式.

   Added in version 3.4.

注釈:

  "multiprocessing" には "threading.active_count()",
  "threading.enumerate()", "threading.settrace()",
  "threading.setprofile()", "threading.Timer" や "threading.local" の
  ような関数はありません。


Connection オブジェクト
-----------------------

Connection オブジェクトは pickle でシリアライズ可能なオブジェクトか文
字列を送ったり、受け取ったりします。そういったオブジェクトはメッセージ
指向の接続ソケットと考えられます。

Connection オブジェクトは通常は "Pipe" を使用して作成されます。 詳細は
リスナーとクライアント も参照してください。

class multiprocessing.connection.Connection

   send(obj)

      コネクションの相手側へ "recv()" を使用して読み込むオブジェクトを
      送ります。

      オブジェクトは pickle でシリアライズ可能でなければなりません。
      pickle が極端に大きすぎる (OS にも依りますが、およそ 32 MiB+) と
      、 "ValueError" 例外が送出されることがあります。

   recv()

      コネクションの相手側から "send()" を使用して送られたオブジェクト
      を返します。 何か受け取るまでブロックします。何も受け取らずにコ
      ネクションの相手側でクローズされた場合 "EOFError" が発生します。

   fileno()

      コネクションが使用するハンドラーか、ファイル記述子を返します。

   close()

      コネクションをクローズします。

      コネクションがガベージコレクトされるときに自動的に呼び出されます
      。

   poll([timeout])

      読み込み可能なデータがあるかどうかを返します。

      *timeout* が指定されていなければすぐに返します。 *timeout* に数
      値を指定すると、最大指定した秒数をブロッキングします。 *timeout*
      に "None" を指定するとタイムアウトせずにずっとブロッキングします
      。

      "multiprocessing.connection.wait()" を使って複数のコネクションオ
      ブジェクトを同時にポーリングできることに注意してください。

   send_bytes(buffer[, offset[, size]])

      *bytes-like object* から完全なメッセージとしてバイトデータを送り
      ます。

      *offset* が指定されると *buffer* のその位置からデータが読み込ま
      れます。 *size* が指定されるとバッファーからその量のデータが読み
      込まれます。非常に大きなバッファー (OS に依存しますが、およそ
      32MiB+) を指定すると、 "ValueError" 例外が発生するかもしれません
      。

   recv_bytes([maxlength])

      コネクションの相手側から送られたバイトデータの完全なメッセージを
      文字列として返します。何か受け取るまでブロックします。受け取るデ
      ータが何も残っておらず、相手側がコネクションを閉じていた場合、
      "EOFError" が送出されます。

      *maxlength* を指定していて、かつメッセージが *maxlength* より長
      い場合、 "OSError" が発生してコネクションからそれ以上読めなくな
      ります。

      バージョン 3.3 で変更: この関数は以前は "IOError" を送出していま
      した。今では "OSError" の別名です。

   recv_bytes_into(buffer[, offset])

      コネクションの相手側から送られたバイトデータを *buffer* に読み込
      み、メッセージのバイト数を返します。 何か受け取るまでブロックし
      ます。何も受け取らずにコネクションの相手側でクローズされた場合
      "EOFError" が発生します。

      *buffer* は書き込み可能な *bytes-like object* でなければなりませ
      ん。 *offset* が与えられたら、その位置からバッファーへメッセージ
      が書き込まれます。 オフセットは *buffer* バイトよりも小さい正の
      数でなければなりません。

      バッファーがあまりに小さいと "BufferTooShort" 例外が発生します。
      "e" が例外インスタンスとすると完全なメッセージは "e.args[0]" で
      確認できます。

   バージョン 3.3 で変更: "Connection.send()" と "Connection.recv()"
   を使用して Connection オブジェクト自体をプロセス間で転送できるよう
   になりました。Connection objects also now support the context
   management protocol -- see コンテキストマネージャ型.  "__enter__()"
   returns the connection object, and "__exit__()" calls "close()".

例えば:

   >>> from multiprocessing import Pipe
   >>> a, b = Pipe()
   >>> a.send([1, 'hello', None])
   >>> b.recv()
   [1, 'hello', None]
   >>> b.send_bytes(b'thank you')
   >>> a.recv_bytes()
   b'thank you'
   >>> import array
   >>> arr1 = array.array('i', range(5))
   >>> arr2 = array.array('i', [0] * 10)
   >>> a.send_bytes(arr1)
   >>> count = b.recv_bytes_into(arr2)
   >>> assert count == len(arr1) * arr1.itemsize
   >>> arr2
   array('i', [0, 1, 2, 3, 4, 0, 0, 0, 0, 0])

警告:

  "Connection.recv()" メソッドは受信したデータを自動的に unpickle 化し
  ます。それはメッセージを送ったプロセスが信頼できる場合を除いてセキュ
  リティリスクになります。そのため "Pipe()" を使用してコネクションオブ
  ジェクトを生成する場合を除いて、何らかの認証処理を実行した後で
  "recv()" や "send()" メソッドのみを使用すべきです。詳細は 認証キー
  を参照してください。

警告:

  もしプロセスがパイプの読み込みまたは書き込み中に kill されると、メッ
  セージの境界がどこなのか分からなくなってしまうので、そのパイプ内のデ
  ータは破損してしまいがちです。


同期プリミティブ
----------------

一般的にマルチプロセスプログラムは、マルチスレッドプログラムほどは同期
プリミティブを必要としません。詳細は "threading" モジュールのドキュメ
ントを参照してください。

マネージャーオブジェクトを使用して同期プリミティブを作成できることも覚
えておいてください。詳細は マネージャー を参照してください。

class multiprocessing.Barrier(parties[, action[, timeout]])

   バリアーオブジェクト: "threading.Barrier" のクローンです。

   Added in version 3.3.

class multiprocessing.BoundedSemaphore([value])

   有限セマフォオブジェクト: "threading.BoundedSemaphore" の類似物です
   。

   よく似た "threading.BoundedSemaphore"  とは、次の一点だけ異なります
   。 "acquire" メソッドの第一引数名は *block* で、"Lock.acquire()" と
   一致しています。

   注釈:

     macOS では "sem_getvalue()" が実装されていないので "Semaphore" と
     区別がつきません。

class multiprocessing.Condition([lock])

   状態変数: "threading.Condition" の別名です。

   *lock* を指定するなら "multiprocessing" の "Lock" か "RLock" オブジ
   ェクトにすべきです。

   バージョン 3.3 で変更: "wait_for()" メソッドが追加されました。

class multiprocessing.Event

   "threading.Event" のクローンです。

class multiprocessing.Lock

   再帰しないロックオブジェクトで、 "threading.Lock" 相当のものです。
   プロセスやスレッドがロックをいったん獲得 (acquire) すると、それに続
   くほかのプロセスやスレッドが獲得しようとする際、それが解放
   (release) されるまではブロックされます。解放はどのプロセス、スレッ
   ドからも行えます。スレッドに対して適用される "threading.Lock" のコ
   ンセプトと振る舞いは、特筆すべきものがない限り、プロセスとスレッド
   に適用される "multiprocessing.Lock" に引き継がれています。

   "Lock" は実際にはファクトリ関数で、デフォルトコンテキストで初期化さ
   れた "multiprocessing.synchronize.Lock" のインスタンスを返すことに
   注意してください。

   "Lock" は *context manager* プロトコルをサポートしています。つまり
   "with" 文で使うことができます。

   acquire(block=True, timeout=None)

      ブロックあり、またはブロックなしでロックを獲得します。

      引数 *block* を "True" (デフォルト) に設定して呼び出した場合、ロ
      ックがアンロック状態になるまでブロックします。ブロックから抜ける
      とそれをロック状態にしてから "True" を返します。
      "threading.Lock.acquire()" の最初の引数とは名前が違っているので
      注意してください。

      引数 *block* の値を "False" にして呼び出すとブロックしません。
      現在ロック状態であれば、直ちに "False" を返します。それ以外の場
      合には、ロックをロック状態にして "True" を返します。

      *timeout* として正の浮動小数点数を与えて呼び出すと、ロックが獲得
      できない限り、指定された秒数だけブロックします。 *timeout* 値に
      負数を与えると、ゼロを与えた場合と同じになります。 *timeout* 値
      の "None" (デフォルト) を与えると、無限にブロックします。
      *timeout* 引数の負数と "None" の扱いは、
      "threading.Lock.acquire()" に実装された動作と異なるので注意して
      ください。 *block* が "False" の場合、 *timeout* は実際的な意味
      を持たなくなるので無視されます。ロックを獲得した場合は "True" 、
      タイムアウトした場合は "False" で戻ります。

   release()

      ロックを解放します。これはロックを獲得したプロセスやスレッドだけ
      でなく、任意のプロセスやスレッドから呼ぶことができます。

      "threading.Lock.release()" と同じように振舞いますが、ロックされ
      ていない場合に呼び出すと "ValueError" となる点だけが違います。

class multiprocessing.RLock

   再帰ロックオブジェクトで、 "threading.RLock" 相当のものです。再帰ロ
   ックオブジェクトはそれを獲得 (acquire) したプロセスやスレッドが解放
   (release) しなければなりません。プロセスやスレッドがロックをいった
   ん獲得すると、同じプロセスやスレッドはブロックされずに再度獲得出来
   ます。そのプロセスやスレッドは獲得した回数ぶん解放しなければなりま
   せん。

   "RLock" は実際にはファクトリ関数で、デフォルトコンテキストで初期化
   された "multiprocessing.synchronize.Lock" のインスタンスを返すこと
   に注意してください。

   "RLock" は *context manager* プロトコルをサポートしています。つまり
   "with" 文で使うことができます。

   acquire(block=True, timeout=None)

      ブロックあり、またはブロックなしでロックを獲得します。

      *block* 引数を "True" にして呼び出した場合、ロックが既にカレント
      プロセスもしくはカレントスレッドが既に所有していない限りは、アン
      ロック状態 (どのプロセス、スレッドも所有していない状態) になるま
      でブロックします。ブロックから抜けるとカレントプロセスもしくはカ
      レントスレッドが (既に持っていなければ) 所有権を得て、再帰レベル
      をインクリメントし、 "True" で戻ります。
      "threading.RLock.acquire()" の実装とはこの最初の引数の振る舞いが
      、その名前自身を始めとしていくつか違うので注意してください。

      *block* 引数を "False" にして呼び出した場合、ブロックしません。
      ロックが他のプロセスもしくはスレッドにより獲得済み (つまり所有さ
      れている) であれば、カレントプロセスまたはカレントスレッドは所有
      権を得ず、再帰レベルも変更せずに、 "False" で戻ります。ロックが
      アンロック状態の場合、カレントプロセスもしくはカレントスレッドは
      所有権を得て再帰レベルがインクリメントされ、 "True" で戻ります。
      (---訳注: *block* の True/False 関係なくここでの説明では「所有権
      を持っている場合の2度目以降の aquire」の説明が欠けています。2度
      目以降の acquire では再帰レベルがインクリメントされて即座に返り
      ます。全体読めばわかるとは思いますが一応。---)

      *timeout* 引数の使い方と振る舞いは "Lock.acquire()" と同じです。
      *timeout* 引数の振る舞いがいくつかの点で
      "threading.RLock.acquire()" と異なるので注意してください。

   release()

      再帰レベルをデクリメントしてロックを解放します。デクリメント後に
      再帰レベルがゼロになった場合、ロックの状態をアンロック (いかなる
      プロセス、いかなるスレッドにも所有されていない状態) にリセットし
      、ロックの状態がアンロックになるのを待ってブロックしているプロセ
      スもしくはスレッドがある場合にはその中のただ一つだけが処理を進行
      できるようにします。デクリメント後も再帰レベルがゼロでない場合、
      ロックの状態はロックのままで、呼び出し側のプロセスもしくはスレッ
      ドに所有されたままになります。

      このメソッドは呼び出しプロセスあるいはスレッドがロックを所有して
      いる場合に限り呼び出してください。所有者でないプロセスもしくはス
      レッドによって呼ばれるか、あるいはアンロック (未所有) 状態で呼ば
      れた場合、 "AssertionError" が送出されます。同じ状況での
      "threading.RLock.release()" 実装とは例外の型が異なるので注意して
      ください。

class multiprocessing.Semaphore([value])

   セマフォオブジェクト: "threading.Semaphore" のクローンです。

   よく似た "threading.BoundedSemaphore"  とは、次の一点だけ異なります
   。 "acquire" メソッドの第一引数名は *block* で、"Lock.acquire()" と
   一致しています。

注釈:

  macOS では "sem_timedwait" がサポートされていないので、"acquire()"
  にタイムアウトを与えて呼ぶと、ループ内でスリープすることでこの関数が
  エミュレートされます。

注釈:

  このパッケージに含まれる機能には、ホストとなるオペレーティングシステ
  ム上で動作している共有セマフォを使用しているものがあります。これが使
  用できない場合には、"multiprocessing.synchronize" モジュールが無効に
  なり、このモジュールのインポート時に "ImportError" が発生します。詳
  細は bpo-3770 を参照してください。


共有 "ctypes" オブジェクト
--------------------------

子プロセスにより継承される共有メモリを使用する共有オブジェクトを作成す
ることができます。

multiprocessing.Value(typecode_or_type, *args, lock=True)

   共有メモリから割り当てられた "ctypes" オブジェクトを返します。 デフ
   ォルトでは、返り値は実際のオブジェクトの同期ラッパーです。オブジェ
   クトそれ自身は、 "Value" の *value* 属性によってアクセスできます。

   *typecode_or_type* は返されるオブジェクトの型を決めます。それは
   ctypes の型か "array" モジュールで使用されるような1文字の型コードか
   のどちらか一方です。 **args* は型のコンストラクターへ渡されます。

   *lock* が "True" (デフォルト) なら、値へ同期アクセスするために新た
   に再帰的なロックオブジェクトが作成されます。 *lock* が "Lock" か
   "RLock" なら値への同期アクセスに使用されます。 *lock* が "False" な
   ら、返されたオブジェクトへのアクセスはロックにより自動的に保護され
   ません。そのため、必ずしも "プロセスセーフ" ではありません。

   "+=" のような演算は、読み込みと書き込みを含むためアトミックでありま
   せん。このため、たとえば自動的に共有の値を増加させたい場合、以下の
   ようにするのでは不十分です

      counter.value += 1

   関連するロックが再帰的 (それがデフォルトです) なら、かわりに次のよ
   うにします

      with counter.get_lock():
          counter.value += 1

   *lock* はキーワード専用引数であることに注意してください。

multiprocessing.Array(typecode_or_type, size_or_initializer, *, lock=True)

   共有メモリから割り当てられた ctypes 配列を返します。デフォルトでは
   、返り値は実際の配列の同期ラッパーです。

   *typecode_or_type* は返される配列の要素の型を決めます。それは
   ctypes の型か "array" モジュールで使用されるような1文字の型コードか
   のどちらか一方です。 *size_or_initializer* が整数なら、配列の長さを
   決定し、その配列はゼロで初期化されます。別の使用方法として
   *size_or_initializer* は配列の初期化に使用されるシーケンスになり、
   そのシーケンス長が配列の長さを決定します。

   *lock* が "True" (デフォルト) なら、値へ同期アクセスするために新た
   なロックオブジェクトが作成されます。 *lock* が "Lock" か "RLock" な
   ら値への同期アクセスに使用されます。 *lock* が "False" なら、返され
   たオブジェクトへのアクセスはロックにより自動的に保護されません。そ
   のため、必ずしも "プロセスセーフ" ではありません。

   *lock* はキーワード引数としてのみ利用可能なことに注意してください。

   "ctypes.c_char" の配列は文字列を格納して取り出せる *value* と *raw*
   属性を持っていることを覚えておいてください。


"multiprocessing.sharedctypes" モジュール
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"multiprocessing.sharedctypes" モジュールは子プロセスに継承される共有
メモリの "ctypes" オブジェクトを割り当てる関数を提供します。

注釈:

  共有メモリのポインターを格納することは可能ではありますが、特定プロセ
  スのアドレス空間の位置を参照するということを覚えておいてください。し
  かし、そのポインターは別のプロセスのコンテキストにおいて無効になる確
  率が高いです。そして、別のプロセスからそのポインターを逆参照しようと
  するとクラッシュを引き起こす可能性があります。

multiprocessing.sharedctypes.RawArray(typecode_or_type, size_or_initializer)

   共有メモリから割り当てられた ctypes 配列を返します。

   *typecode_or_type* は返される配列の要素の型を決めます。それは
   ctypes の型か "array" モジュールで使用されるような1文字の型コードの
   どちらか一方です。 *size_or_initializer* が整数なら、それが配列の長
   さになり、その配列はゼロで初期化されます。別の使用方法として
   *size_or_initializer* には配列の初期化に使用されるシーケンスを設定
   することもでき、その場合はシーケンスの長さが配列の長さになります。

   要素を取得したり設定したりすることは潜在的に非アトミックであること
   に注意してください。ロックを使用して自動的に同期化されたアクセスを
   保証するには "Array()" を使用してください。

multiprocessing.sharedctypes.RawValue(typecode_or_type, *args)

   共有メモリから割り当てられた ctypes オブジェクトを返します。

   *typecode_or_type* は返されるオブジェクトの型を決めます。それは
   ctypes の型か "array" モジュールで使用されるような1文字の型コードか
   のどちらか一方です。 **args* は型のコンストラクターへ渡されます。

   値を取得したり設定したりすることは潜在的に非アトミックであることに
   注意してください。ロックを使用して自動的に同期化されたアクセスを保
   証するには "Value()" を使用してください。

   "ctypes.c_char" の配列は文字列を格納して取り出せる "value" と "raw"
   属性を持っていることを覚えておいてください。詳細は "ctypes" を参照
   してください。

multiprocessing.sharedctypes.Array(typecode_or_type, size_or_initializer, *, lock=True)

   "RawArray()" と同様ですが、 *lock* の値によっては ctypes 配列をその
   まま返す代わりに、プロセスセーフな同期ラッパーが返されます。

   *lock* が "True" (デフォルト) なら、値へ同期アクセスするために新た
   な ロックオブジェクトが作成されます。 *lock* が "Lock" か "RLock"
   なら値への同期アクセスに使用されます。 *lock* が "False" なら、返さ
   れた オブジェクトへのアクセスはロックにより自動的に保護されません。
   そのため、必ずしも "プロセスセーフ" ではありません。

   *lock* はキーワード専用引数であることに注意してください。

multiprocessing.sharedctypes.Value(typecode_or_type, *args, lock=True)

   "RawValue()" と同様ですが、 *lock* の値によっては ctypes オブジェク
   トをそのまま返す代わりに、プロセスセーフな同期ラッパーが返されます
   。

   *lock* が "True" (デフォルト) なら、値へ同期アクセスするために新た
   な ロックオブジェクトが作成されます。 *lock* が "Lock" か "RLock"
   なら値への同期アクセスに使用されます。 *lock* が "False" なら、返さ
   れた オブジェクトへのアクセスはロックにより自動的に保護されません。
   そのため、必ずしも "プロセスセーフ" ではありません。

   *lock* はキーワード専用引数であることに注意してください。

multiprocessing.sharedctypes.copy(obj)

   共有メモリから割り当てられた ctypes オブジェクト *obj* をコピーした
   オブジェクトを返します。

multiprocessing.sharedctypes.synchronized(obj[, lock])

   同期アクセスに *lock* を使用する ctypes オブジェクトのためにプロセ
   スセーフなラッパーオブジェクトを返します。 *lock* が "None" (デフォ
   ルト) なら、 "multiprocessing.RLock" オブジェクトが自動的に作成され
   ます。

   同期ラッパーがラップするオブジェクトに加えて2つのメソッドがあります
   。 "get_obj()" はラップされたオブジェクトを返します。 "get_lock()"
   は同期のために使用されるロックオブジェクトを返します。

   ラッパー経由で ctypes オブジェクトにアクセスすることは raw ctypes
   オブジェクトへアクセスするよりずっと遅くなることに注意してください
   。

   バージョン 3.5 で変更: synchronized オブジェクトは *コンテキストマ
   ネージャ* プロトコルをサポートしています。

次の表は通常の ctypes 構文で共有メモリから共有 ctypes オブジェクトを作
成するための構文を比較します。 ("MyStruct" テーブル内には
"ctypes.Structure" のサブクラスがあります。)

+----------------------+----------------------------+-----------------------------+
| ctypes               | type を使用する            | typecode を使用する         |
|                      | sharedctypes               | sharedctypes                |
|======================|============================|=============================|
| c_double(2.4)        | RawValue(c_double, 2.4)    | RawValue('d', 2.4)          |
+----------------------+----------------------------+-----------------------------+
| MyStruct(4, 6)       | RawValue(MyStruct, 4, 6)   |                             |
+----------------------+----------------------------+-----------------------------+
| (c_short * 7)()      | RawArray(c_short, 7)       | RawArray('h', 7)            |
+----------------------+----------------------------+-----------------------------+
| (c_int * 3)(9, 2, 8) | RawArray(c_int, (9, 2, 8)) | RawArray('i', (9, 2, 8))    |
+----------------------+----------------------------+-----------------------------+

以下に子プロセスが多くの ctypes オブジェクトを変更する例を紹介します:

   from multiprocessing import Process, Lock
   from multiprocessing.sharedctypes import Value, Array
   from ctypes import Structure, c_double

   class Point(Structure):
       _fields_ = [('x', c_double), ('y', c_double)]

   def modify(n, x, s, A):
       n.value **= 2
       x.value **= 2
       s.value = s.value.upper()
       for a in A:
           a.x **= 2
           a.y **= 2

   if __name__ == '__main__':
       lock = Lock()

       n = Value('i', 7)
       x = Value(c_double, 1.0/3.0, lock=False)
       s = Array('c', b'hello world', lock=lock)
       A = Array(Point, [(1.875,-6.25), (-5.75,2.0), (2.375,9.5)], lock=lock)

       p = Process(target=modify, args=(n, x, s, A))
       p.start()
       p.join()

       print(n.value)
       print(x.value)
       print(s.value)
       print([(a.x, a.y) for a in A])

結果は以下のように表示されます

   49
   0.1111111111111111
   HELLO WORLD
   [(3.515625, 39.0625), (33.0625, 4.0), (5.640625, 90.25)]


マネージャー
------------

マネージャーは異なるプロセス間で共有されるデータの作成方法を提供します
。これには別のマシン上で走るプロセス間のネットワーク越しの共有も含まれ
ます。マネージャーオブジェクトは *共有オブジェクト* を管理するサーバー
プロセスを制御します。他のプロセスはプロキシ経由で共有オブジェクトへア
クセスすることができます。

multiprocessing.Manager()

   プロセス間でオブジェクトを共有するために使用される "SyncManager" オ
   ブジェクトを返します。返されたマネージャーオブジェクトは生成される
   子プロセスに対応付けられ、共有オブジェクトを作成するメソッドや、共
   有オブジェクトに対応するプロキシを返すメソッドを持ちます。

マネージャープロセスは親プロセスが終了するか、ガベージコレクトされると
停止します。マネージャークラスは "multiprocessing.managers" モジュール
で定義されています:

class multiprocessing.managers.BaseManager(address=None, authkey=None, serializer='pickle', ctx=None, *, shutdown_timeout=1.0)

   BaseManager オブジェクトを作成します。

   作成後、"start()" または "get_server().serve_forever()" を呼び出し
   て、マネージャーオブジェクトが、開始されたマネージャープロセスを確
   実に参照するようにしてください。

   *address* はマネージャープロセスが新たなコネクションを待ち受けるア
   ドレスです。*address* が "None" の場合、任意のアドレスが設定されま
   す。

   *authkey* はサーバープロセスへ接続しようとするコネクションの正当性
   を検証するために 使用される認証キーです。*authkey* が "None" の場合
   "current_process().authkey" が使用されます。*authkey* を使用する場
   合はバイト文字列でなければなりません。

   *serializer* must be "'pickle'" (use "pickle" serialization) or
   "'xmlrpclib'" (use "xmlrpc.client" serialization).

   *ctx* is a context object, or "None" (use the current context). See
   the "get_context()" function.

   *shutdown_timeout* is a timeout in seconds used to wait until the
   process used by the manager completes in the "shutdown()" method.
   If the shutdown times out, the process is terminated. If
   terminating the process also times out, the process is killed.

   バージョン 3.11 で変更: *shutdown_timeout* パラメータを追加しました
   。

   start([initializer[, initargs]])

      マネージャーを開始するためにサブプロセスを開始します。
      *initializer* が "None" でなければ、サブプロセスは開始時に
      "initializer(*initargs)" を呼び出します。

   get_server()

      マネージャーの制御下にある実際のサーバーを表す "Server" オブジェ
      クトを返します。 "Server" オブジェクトは "serve_forever()" メソ
      ッドをサポートします:

         >>> from multiprocessing.managers import BaseManager
         >>> manager = BaseManager(address=('', 50000), authkey=b'abc')
         >>> server = manager.get_server()
         >>> server.serve_forever()

      "Server" はさらに "address" 属性も持っています。

   connect()

      ローカルからリモートのマネージャーオブジェクトへ接続します:

         >>> from multiprocessing.managers import BaseManager
         >>> m = BaseManager(address=('127.0.0.1', 50000), authkey=b'abc')
         >>> m.connect()

   shutdown()

      マネージャーが使用するプロセスを停止します。これはサーバープロセ
      スを開始するために "start()" が使用された場合のみ有効です。

      これは複数回呼び出すことができます。

   register(typeid[, callable[, proxytype[, exposed[, method_to_typeid[, create_method]]]]])

      マネージャークラスで呼び出し可能オブジェクト(callable)や型を登録
      するために使用されるクラスメソッドです。

      *typeid* は特に共有オブジェクトの型を識別するために使用される "
      型識別子" です。これは文字列でなければなりません。

      *callable* はこの型識別子のオブジェクトを作成するために使用され
      る呼び出し可能オブジェクトです。マネージャーインスタンスが
      "connect()" メソッドを使ってサーバーに接続されているか、
      *create_method* 引数が "False" の場合は、 "None" でも構いません
      。

      *proxytype* はこの *typeid* で共有オブジェクトのプロキシを作成す
      るために使用される "BaseProxy" のサブクラスです。 "None" の場合
      、プロキシクラスは自動的に作成されます。

      *exposed* は "BaseProxy._callmethod()" を使用したアクセスが許さ
      れるべき typeid をプロキシするメソッド名のシーケンスを指定するた
      めに使用されます (*exposed* が "None" の場合
      "proxytype._exposed_" が存在すればそれが代わりに使用されます)。
      *exposed* リストが指定されない場合、共有オブジェクトのすべての "
      パブリックメソッド" がアクセス可能になります。 (ここでいう "パブ
      リックメソッド" とは "__call__()" メソッドを持つものと名前が
      "'_'" で始まらないあらゆる属性を意味します。)

      *method_to_typeid* はプロキシが返す exposed メソッドの返り値の型
      を指定するために使用されるマッピングで、メソッド名を typeid 文字
      列にマップします。 (*method_to_typeid* が "None" の場合
      "proxytype._method_to_typeid_" が存在すれば、それが代わりに使用
      されます。) メソッド名がこのマッピングのキーではないか、マッピン
      グが "None" の場合、そのメソッドによって返されるオブジェクトが値
      として (by value) コピーされます。

      *create_method* は、共有オブジェクトを作成し、それに対するプロキ
      シを返すようサーバープロセスに伝える、名前 *typeid* のメソッドを
      作成するかを決定します。デフォルトでは "True" です。

   "BaseManager" インスタンスも読み出し専用属性を1つ持っています:

   address

      マネージャーが使用するアドレスです。

   バージョン 3.3 で変更: マネージャーオブジェクトはコンテキストマネー
   ジメント・プロトコルをサポートします -- コンテキストマネージャ型 を
   参照してください。 "__enter__()" は (まだ開始していない場合) サーバ
   ープロセスを開始してから、マネージャーオブジェクトを返します。
   "__exit__()" は "shutdown()" を呼び出します。旧バージョンでは、
   "__enter__()" はマネージャーのサーバープロセスがまだ開始していなか
   った場合でもプロセスを開始しませんでした。

class multiprocessing.managers.SyncManager

   プロセス間の同期のために使用される "BaseManager" のサブクラスです。
   "multiprocessing.Manager()" はこの型のオブジェクトを返します。

   Its methods create and return Proxy オブジェクト for a number of
   commonly used data types to be synchronized across processes. This
   notably includes shared lists and dictionaries.

   Barrier(parties[, action[, timeout]])

      共有 "threading.Barrier" オブジェクトを作成して、そのプロキシを
      返します。

      Added in version 3.3.

   BoundedSemaphore([value])

      共有 "threading.BoundedSemaphore" オブジェクトを作成して、そのプ
      ロキシを返します。

   Condition([lock])

      共有 "threading.Condition" オブジェクトを作成して、そのプロキシ
      を返します。

      *lock* が提供される場合 "threading.Lock" か "threading.RLock" オ
      ブジェクトのためのプロキシになります。

      バージョン 3.3 で変更: "wait_for()" メソッドが追加されました。

   Event()

      共有 "threading.Event" オブジェクトを作成して、そのプロキシを返
      します。

   Lock()

      共有 "threading.Lock" オブジェクトを作成して、そのプロキシを返し
      ます。

   Namespace()

      共有 "Namespace" オブジェクトを作成して、そのプロキシを返します
      。

   Queue([maxsize])

      共有 "queue.Queue" オブジェクトを作成して、そのプロキシを返しま
      す。

   RLock()

      共有 "threading.RLock" オブジェクトを作成して、そのプロキシを返
      します。

   Semaphore([value])

      共有 "threading.Semaphore" オブジェクトを作成して、そのプロキシ
      を返します。

   Array(typecode, sequence)

      配列を作成して、そのプロキシを返します。

   Value(typecode, value)

      書き込み可能な "value" 属性を作成して、そのプロキシを返します。

   dict()
   dict(mapping)
   dict(sequence)

      共有 "dict" オブジェクトを作成して、そのプロキシを返します。

   list()
   list(sequence)

      共有 "list" オブジェクトを作成して、そのプロキシを返します。

   バージョン 3.6 で変更: 共有オブジェクトは入れ子もできます。 例えば
   、共有リストのような共有コンテナオブジェクトは、 "SyncManager" がま
   とめて管理し同期を取っている他の共有オブジェクトを保持できます。

class multiprocessing.managers.Namespace

   "SyncManager" に登録することのできる型です。

   Namespace オブジェクトにはパブリックなメソッドはありませんが、書き
   込み可能な属性を持ちます。そのオブジェクト表現はその属性の値を表示
   します。

   しかし、Namespace オブジェクトのためにプロキシを使用するとき "'_'"
   が先頭に付く属性はプロキシの属性になり、参照対象の属性にはなりませ
   ん:

      >>> mp_context = multiprocessing.get_context('spawn')
      >>> manager = mp_context.Manager()
      >>> Global = manager.Namespace()
      >>> Global.x = 10
      >>> Global.y = 'hello'
      >>> Global._z = 12.3    # this is an attribute of the proxy
      >>> print(Global)
      Namespace(x=10, y='hello')


カスタマイズされたマネージャー
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

独自のマネージャーを作成するには、"BaseManager" のサブクラスを作成して
、 マネージャークラスで呼び出し可能なオブジェクトか新たな型を登録する
ために "register()" クラスメソッドを使用します。例えば:

   from multiprocessing.managers import BaseManager

   class MathsClass:
       def add(self, x, y):
           return x + y
       def mul(self, x, y):
           return x * y

   class MyManager(BaseManager):
       pass

   MyManager.register('Maths', MathsClass)

   if __name__ == '__main__':
       with MyManager() as manager:
           maths = manager.Maths()
           print(maths.add(4, 3))         # prints 7
           print(maths.mul(7, 8))         # prints 56


リモートマネージャーを使用する
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

あるマシン上でマネージャーサーバーを実行して、他のマシンからそのサーバ
ーを使用するクライアントを持つことができます(ファイアウォールを通過で
きることが前提)。

次のコマンドを実行することでリモートクライアントからアクセスを受け付け
る1つの共有キューのためにサーバーを作成します:

   >>> from multiprocessing.managers import BaseManager
   >>> from queue import Queue
   >>> queue = Queue()
   >>> class QueueManager(BaseManager): pass
   >>> QueueManager.register('get_queue', callable=lambda:queue)
   >>> m = QueueManager(address=('', 50000), authkey=b'abracadabra')
   >>> s = m.get_server()
   >>> s.serve_forever()

あるクライアントからサーバーへのアクセスは次のようになります:

   >>> from multiprocessing.managers import BaseManager
   >>> class QueueManager(BaseManager): pass
   >>> QueueManager.register('get_queue')
   >>> m = QueueManager(address=('foo.bar.org', 50000), authkey=b'abracadabra')
   >>> m.connect()
   >>> queue = m.get_queue()
   >>> queue.put('hello')

別のクライアントもそれを使用することができます:

   >>> from multiprocessing.managers import BaseManager
   >>> class QueueManager(BaseManager): pass
   >>> QueueManager.register('get_queue')
   >>> m = QueueManager(address=('foo.bar.org', 50000), authkey=b'abracadabra')
   >>> m.connect()
   >>> queue = m.get_queue()
   >>> queue.get()
   'hello'

ローカルプロセスもそのキューへアクセスすることができます。クライアント
上で上述のコードを使用してアクセスします:

   >>> from multiprocessing import Process, Queue
   >>> from multiprocessing.managers import BaseManager
   >>> class Worker(Process):
   ...     def __init__(self, q):
   ...         self.q = q
   ...         super().__init__()
   ...     def run(self):
   ...         self.q.put('local hello')
   ...
   >>> queue = Queue()
   >>> w = Worker(queue)
   >>> w.start()
   >>> class QueueManager(BaseManager): pass
   ...
   >>> QueueManager.register('get_queue', callable=lambda: queue)
   >>> m = QueueManager(address=('', 50000), authkey=b'abracadabra')
   >>> s = m.get_server()
   >>> s.serve_forever()


Proxy オブジェクト
------------------

プロキシは別のプロセスで(おそらく)有効な共有オブジェクトを *参照する*
オブジェクトです。共有オブジェクトはプロキシの *参照対象* になるという
ことができます。複数のプロキシオブジェクトが同じ参照対象を持つ可能性も
あります。

プロキシオブジェクトはその参照対象の対応するメソッドを呼び出すメソッド
を持ちます (そうは言っても、参照対象のすべてのメソッドが必ずしもプロキ
シ経由で利用可能なわけではありません)。 この方法で、プロキシオブジェク
トはまるでその参照先と同じように使えます:

   >>> mp_context = multiprocessing.get_context('spawn')
   >>> manager = mp_context.Manager()
   >>> l = manager.list([i*i for i in range(10)])
   >>> print(l)
   [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
   >>> print(repr(l))
   <ListProxy object, typeid 'list' at 0x...>
   >>> l[4]
   16
   >>> l[2:5]
   [4, 9, 16]

プロキシに "str()" を適用すると参照対象のオブジェクト表現を返すのに対
して、 "repr()" を適用するとプロキシのオブジェクト表現を返すことに注意
してください。

プロキシオブジェクトの重要な機能は pickle 化ができることで、これにより
プロセス間での受け渡しができます。 そのため、参照対象が Proxy オブジェ
クト を持てます。 これによって管理されたリスト、辞書、その他 Proxy オ
ブジェクト をネストできます:

   >>> a = manager.list()
   >>> b = manager.list()
   >>> a.append(b)         # referent of a now contains referent of b
   >>> print(a, b)
   [<ListProxy object, typeid 'list' at ...>] []
   >>> b.append('hello')
   >>> print(a[0], b)
   ['hello'] ['hello']

同様に、辞書とリストのプロキシも他のプロキシの内部に入れてネストできま
す:

   >>> l_outer = manager.list([ manager.dict() for i in range(2) ])
   >>> d_first_inner = l_outer[0]
   >>> d_first_inner['a'] = 1
   >>> d_first_inner['b'] = 2
   >>> l_outer[1]['c'] = 3
   >>> l_outer[1]['z'] = 26
   >>> print(l_outer[0])
   {'a': 1, 'b': 2}
   >>> print(l_outer[1])
   {'c': 3, 'z': 26}

(プロキシでない) 標準の "list" オブジェクトや "dict" オブジェクトが参
照対象に含まれていた場合、それらの可変な値の変更はマネージャーからは伝
搬されません。 というのも、プロキシには参照対象の中に含まれる値がいつ
変更されたかを知る術が無いのです。 しかし、コンテナプロキシに値を保存
する (これはプロキシオブジェクトの "__setitem__" を起動します) 場合は
マネージャーを通して変更が伝搬され、その要素を実際に変更するために、コ
ンテナプロキシに変更後の値が再代入されます:

   # create a list proxy and append a mutable object (a dictionary)
   lproxy = manager.list()
   lproxy.append({})
   # now mutate the dictionary
   d = lproxy[0]
   d['a'] = 1
   d['b'] = 2
   # at this point, the changes to d are not yet synced, but by
   # updating the dictionary, the proxy is notified of the change
   lproxy[0] = d

This approach is perhaps less convenient than employing nested Proxy
オブジェクト for most use cases but also demonstrates a level of
control over the synchronization.

注釈:

  "multiprocessing" のプロキシ型は値による比較に対して何もサポートしま
  せん。そのため、例えば以下のようになります:

     >>> manager.list([1,2,3]) == [1,2,3]
     False

  比較を行いたいときは参照対象のコピーを使用してください。

class multiprocessing.managers.BaseProxy

   プロキシオブジェクトは "BaseProxy" のサブクラスのインスタンスです。

   _callmethod(methodname[, args[, kwds]])

      プロキシの参照対象のメソッドの実行結果を返します。

      "proxy" がプロキシで、プロキシ内の参照対象が "obj" ならこの式

         proxy._callmethod(methodname, args, kwds)

      はこの式を評価します

         getattr(obj, methodname)(*args, **kwds)

      (マネージャープロセス内の)。

      返される値はその呼び出し結果のコピーか、新たな共有オブジェクトに
      対するプロキシになります。詳細は "BaseManager.register()" の
      *method_to_typeid* 引数のドキュメントを参照してください。

      その呼び出しによって例外が発生した場合、"_callmethod()" によって
      その例外は再送出されます。他の例外がマネージャープロセスで発生し
      たなら、"RemoteError" 例外に変換されたものが "_callmethod()" に
      よって送出されます。

      特に *methodname* が *公開* されていない場合は例外が発生すること
      に注意してください。

      "_callmethod()" の使用例になります:

         >>> l = manager.list(range(10))
         >>> l._callmethod('__len__')
         10
         >>> l._callmethod('__getitem__', (slice(2, 7),)) # equivalent to l[2:7]
         [2, 3, 4, 5, 6]
         >>> l._callmethod('__getitem__', (20,))          # equivalent to l[20]
         Traceback (most recent call last):
         ...
         IndexError: list index out of range

   _getvalue()

      参照対象のコピーを返します。

      参照対象が unpickle 化できるなら例外を発生します。

   __repr__()

      プロキシオブジェクトのオブジェクト表現を返します。

   __str__()

      参照対象のオブジェクト表現を返します。


クリーンアップ
~~~~~~~~~~~~~~

プロキシオブジェクトは弱参照(weakref)コールバックを使用します。プロキ
シオブジェクトがガベージコレクトされるときにその参照対象が所有するマネ
ージャーからその登録を取り消せるようにするためです。

共有オブジェクトはプロキシが参照しなくなったときにマネージャープロセス
から削除されます。


プロセスプール
--------------

"Pool" クラスでタスクを実行するプロセスのプールを作成することができま
す。

class multiprocessing.pool.Pool([processes[, initializer[, initargs[, maxtasksperchild[, context]]]]])

   プロセスプールオブジェクトは、ジョブを送り込めるワーカープロセスの
   プールを制御します。タイムアウトやコールバックのある非同期の実行を
   サポートし、並列 map 実装を持ちます。

   *processes* is the number of worker processes to use.  If
   *processes* is "None" then the number returned by "os.cpu_count()"
   is used.

   *initializer* が "None" ではない場合、各ワーカープロセスは開始時に
   "initializer(*initargs)" を呼び出します。

   *maxtasksperchild* は、ワーカープロセスが exit して新たなワーカープ
   ロセスと置き替えられるまでの間に、ワーカープロセスが完了することの
   できるタスクの数です。この設定により未利用のリソースが解放されるよ
   うなります。デフォルトの *maxtasksperchild* は "None" で、これはワ
   ーカープロセスがプールと同じ期間だけ生き続けるということを意味しま
   す。

   *context* はワーカープロセスを開始するために使用されるコンテキスト
   の指定に使用できます。通常プールは関数 "multiprocessing.Pool()" か
   コンテキストオブジェクトの "Pool()" メソッドを使用して作成されます
   。どちらの場合でも *context* は適切に設定されます。

   プールオブジェクトのメソッドは、そのプールを作成したプロセスのみが
   呼び出すべきです。

   警告:

     "multiprocessing.pool" objects have internal resources that need
     to be properly managed (like any other resource) by using the
     pool as a context manager or by calling "close()" and
     "terminate()" manually. Failure to do this can lead to the
     process hanging on finalization.Note that it is **not correct**
     to rely on the garbage collector to destroy the pool as CPython
     does not assure that the finalizer of the pool will be called
     (see "object.__del__()" for more information).

   バージョン 3.2 で変更: Added the *maxtasksperchild* parameter.

   バージョン 3.4 で変更: *context* パラメータを追加しました。

   注釈:

     "Pool" 中のワーカープロセスは、典型的にはプールのワークキューの存
     続期間とちょうど同じだけ生き続けます。ワーカーに確保されたリソー
     スを解放するために (Apache, mod_wsgi, などのような) 他のシステム
     によく見られるパターンは、プール内のワーカーが設定された量だけの
     仕事を完了したら exit とクリーンアップを行い、古いプロセスを置き
     換えるために新しいプロセスを生成するというものです。 "Pool" の
     *maxtasksperchild* 引数は、この能力をエンドユーザーに提供します。

   apply(func[, args[, kwds]])

      引数 *args* とキーワード引数 *kwds* を伴って *func* を呼びます。
      結果が準備できるまでブロックします。このブロックがあるため、
      "apply_async()" の方が並行作業により適しています。加えて、
      *func* は、プール内の1つのワーカーだけで実行されます。

   apply_async(func[, args[, kwds[, callback[, error_callback]]]])

      "apply()" メソッドの派生版で "AsyncResult" オブジェクトを返しま
      す。

      *callback* が指定された場合、それは単一の引数を受け取る呼び出し
      可能オブジェクトでなければなりません。結果を返せるようになったと
      きに *callback* が結果オブジェクトに対して適用されます。ただし呼
      び出しが失敗した場合は、代わりに *error_callback* が適用されます
      。

      *error_callback* が指定された場合、それは単一の引数を受け取る呼
      び出し可能オブジェクトでなければなりません。対象の関数が失敗した
      場合、例外インスタンスを伴って *error_callback* が呼ばれます。

      コールバックは直ちに完了すべきです。なぜなら、そうしなければ、結
      果を扱うスレッドがブロックするからです。

   map(func, iterable[, chunksize])

      "map()" 組み込み関数の並列版です (*iterable* な引数を1つだけサポ
      ートするという違いはあります。もしも複数のイテラブルを使いたいの
      ならば "starmap()" を参照)。結果が出るまでブロックします。

      このメソッドはイテラブルをいくつものチャンクに分割し、プロセスプ
      ールにそれぞれ独立したタスクとして送ります。(概算の) チャンクサ
      イズは *chunksize* を正の整数に設定することで指定できます。

      Note that it may cause high memory usage for very long
      iterables. Consider using "imap()" or "imap_unordered()" with
      explicit *chunksize* option for better efficiency.

   map_async(func, iterable[, chunksize[, callback[, error_callback]]])

      "map()" メソッドの派生版で "AsyncResult" オブジェクトを返します
      。

      *callback* が指定された場合、それは単一の引数を受け取る呼び出し
      可能オブジェクトでなければなりません。結果を返せるようになったと
      きに *callback* が結果オブジェクトに対して適用されます。ただし呼
      び出しが失敗した場合は、代わりに *error_callback* が適用されます
      。

      *error_callback* が指定された場合、それは単一の引数を受け取る呼
      び出し可能オブジェクトでなければなりません。対象の関数が失敗した
      場合、例外インスタンスを伴って *error_callback* が呼ばれます。

      コールバックは直ちに完了すべきです。なぜなら、そうしなければ、結
      果を扱うスレッドがブロックするからです。

   imap(func, iterable[, chunksize])

      "map()" の遅延評価版です。

      *chunksize* 引数は "map()" メソッドで使用されるものと同じです。
      引数 iterable がとても長いなら *chunksize* に大きな値を指定して
      使用する方がデフォルト値の "1" を使用するよりもジョブの完了が **
      かなり** 速くなります。

      また *chunksize* が "1" の場合 "imap()" メソッドが返すイテレータ
      ーの "next()" メソッドはオプションで *timeout* パラメーターを持
      ちます。 "next(timeout)" は、その結果が *timeout* 秒以内に返され
      ないときに "multiprocessing.TimeoutError" を発生させます。

   imap_unordered(func, iterable[, chunksize])

      イテレーターが返す結果の順番が任意の順番で良いと見なされることを
      除けば "imap()" と同じです。 (ワーカープロセスが1つしかない場合
      のみ "正しい" 順番になることが保証されます。)

   starmap(func, iterable[, chunksize])

      *iterable* の要素が、引数として unpack されるイテレート可能オブ
      ジェクトであると期待される以外は、 "map()" と似ています。

      そのため、*iterable* が "[(1,2), (3, 4)]" なら、結果は
      "[func(1,2), func(3,4)]" になります。

      Added in version 3.3.

   starmap_async(func, iterable[, chunksize[, callback[, error_callback]]])

      "starmap()" と "map_async()" の組み合わせです。 イテレート可能オ
      ブジェクトの *iterable* をイテレートして、 unpack したイテレート
      可能オブジェクトを伴って *func* を呼び出します。結果オブジェクト
      を返します。

      Added in version 3.3.

   close()

      これ以上プールでタスクが実行されないようにします。すべてのタスク
      が完了した後でワーカープロセスが終了します。

   terminate()

      実行中の処理を完了させずにワーカープロセスをすぐに停止します。プ
      ールオブジェクトがガベージコレクトされるときに "terminate()" が
      呼び出されます。

   join()

      ワーカープロセスが終了するのを待ちます。 "join()" を使用する前に
      "close()" か "terminate()" を呼び出さなければなりません。

   バージョン 3.3 で変更: Pool オブジェクトがコンテキストマネージメン
   ト・プロトコルをサポートするようになりました。 -- コンテキストマネ
   ージャ型 を参照してください。 "__enter__()" は Pool オブジェクトを
   返します。また "__exit__()" は "terminate()" を呼び出します。

class multiprocessing.pool.AsyncResult

   "Pool.apply_async()" や "Pool.map_async()" で返される結果のクラスで
   す。

   get([timeout])

      結果を受け取ったときに返します。 *timeout* が "None" ではなくて
      、その結果が *timeout* 秒以内に受け取れない場合
      "multiprocessing.TimeoutError" が発生します。リモートの呼び出し
      が例外を発生させる場合、その例外は "get()" が再発生させます。

   wait([timeout])

      その結果が有効になるか *timeout* 秒経つまで待ちます。

   ready()

      その呼び出しが完了しているかどうかを返します。

   successful()

      その呼び出しが例外を発生させることなく完了したかどうかを返します
      。その結果が返せる状態でない場合 "ValueError" が発生します。

      バージョン 3.7 で変更: If the result is not ready, "ValueError"
      is raised instead of "AssertionError".

次の例はプールの使用例を紹介します:

   from multiprocessing import Pool
   import time

   def f(x):
       return x*x

   if __name__ == '__main__':
       with Pool(processes=4) as pool:         # start 4 worker processes
           result = pool.apply_async(f, (10,)) # evaluate "f(10)" asynchronously in a single process
           print(result.get(timeout=1))        # prints "100" unless your computer is *very* slow

           print(pool.map(f, range(10)))       # prints "[0, 1, 4,..., 81]"

           it = pool.imap(f, range(10))
           print(next(it))                     # prints "0"
           print(next(it))                     # prints "1"
           print(it.next(timeout=1))           # prints "4" unless your computer is *very* slow

           result = pool.apply_async(time.sleep, (10,))
           print(result.get(timeout=1))        # raises multiprocessing.TimeoutError


リスナーとクライアント
----------------------

通常、プロセス間でメッセージを渡すにはキューを使用するか "Pipe()" が返
す "Connection" オブジェクトを使用します。

しかし "multiprocessing.connection" モジュールにはさらに柔軟な仕組みが
あります。 このモジュールは、基本的にはソケットもしくは Windows の名前
付きパイプを扱う高レベルのメッセージ指向 API を提供します。また、
"hmac" モジュールを使用した *ダイジェスト認証* や同時の複数接続のポー
リングもサポートします。

multiprocessing.connection.deliver_challenge(connection, authkey)

   ランダム生成したメッセージをコネクションの相手側へ送信して応答を待
   ちます。

   その応答がキーとして *authkey* を使用するメッセージのダイジェストと
   一致する場合、 コネクションの相手側へ歓迎メッセージを送信します。
   そうでなければ "AuthenticationError" を発生させます。

multiprocessing.connection.answer_challenge(connection, authkey)

   メッセージを受信して、そのキーとして *authkey* を使用するメッセージ
   のダイジェストを計算し、ダイジェストを送り返します。

   歓迎メッセージを受け取れない場合 "AuthenticationError" が発生します
   。

multiprocessing.connection.Client(address[, family[, authkey]])

   *address* で渡したアドレスを使用するリスナーに対してコネクションを
   確立しようとして "Connection" を返します。

   コネクション種別は *family* 引数で決定しますが、一般的には
   *address* のフォーマットから推測できるので、これは指定されません。
   (アドレスフォーマット を参照してください)

   If *authkey* is given and not "None", it should be a byte string
   and will be used as the secret key for an HMAC-based authentication
   challenge. No authentication is done if *authkey* is "None".
   "AuthenticationError" is raised if authentication fails. See 認証キ
   ー.

class multiprocessing.connection.Listener([address[, family[, backlog[, authkey]]]])

   コネクションを '待ち受ける' 束縛されたソケットか Windows の名前付き
   パイプのラッパーです。

   *address* はリスナーオブジェクトの束縛されたソケットか名前付きパイ
   プが使用するアドレスです。

   注釈:

     '0.0.0.0' のアドレスを使用する場合、Windows 上の終点へ接続するこ
     とができません。終点へ接続したい場合は '127.0.0.1' を使用すべきで
     す。

   *family* は使用するソケット(名前付きパイプ)の種別です。これは
   "'AF_INET'" (TCP ソケット), "'AF_UNIX'" (Unix ドメインソケット) ま
   たは "'AF_PIPE'" (Windows 名前付きパイプ) という文字列のどれか1つに
   なります。これらのうち "'AF_INET'" のみが利用可能であることが保証さ
   れています。 *family* が "None" の場合 *address* のフォーマットから
   推測されたものが使用されます。 *address* も "None" の場合はデフォル
   トが選択されます。詳細は アドレスフォーマット を参照してください。
   *family* が "'AF_UNIX'" で *address* が "None" の場合
   "tempfile.mkstemp()" を使用して作成されたプライベートな一時ディレク
   トリにソケットが作成されます。

   リスナーオブジェクトがソケットを使用する場合、ソケットに束縛される
   ときに *backlog* (デフォルトでは1つ) がソケットの "listen()" メソッ
   ドに対して渡されます。

   If *authkey* is given and not "None", it should be a byte string
   and will be used as the secret key for an HMAC-based authentication
   challenge. No authentication is done if *authkey* is "None".
   "AuthenticationError" is raised if authentication fails. See 認証キ
   ー.

   accept()

      リスナーオブジェクトの名前付きパイプか束縛されたソケット上でコネ
      クションを 受け付けて "Connection" オブジェクトを返します。 認証
      が失敗した場合 "AuthenticationError" が発生します。

   close()

      リスナーオブジェクトの名前付きパイプか束縛されたソケットをクロー
      ズします。これはリスナーがガベージコレクトされるときに自動的に呼
      ばれます。そうは言っても、明示的に close() を呼び出す方が望まし
      いです。

   リスナーオブジェクトは次の読み出し専用属性を持っています:

   address

      リスナーオブジェクトが使用中のアドレスです。

   last_accepted

      最後にコネクションを受け付けたアドレスです。有効なアドレスがない
      場合は "None" になります。

   バージョン 3.3 で変更: Listener オブジェクトがコンテキストマネージ
   メント・プロトコルをサポートするようになりました。 -- コンテキスト
   マネージャ型 を参照してください。 "__enter__()" はリスナーオブジェ
   クトを返します。また "__exit__()" は "close()" を呼び出します。

multiprocessing.connection.wait(object_list, timeout=None)

   *object_list* 中のオブジェクトが準備ができるまで待機します。準備が
   できた *object_list* 中のオブジェクトのリストを返します。*timeout*
   が浮動小数点なら、最大でその秒数だけ呼び出しがブロックします。
   *timeout* が "None" の場合、無制限の期間ブロックします。負のタイム
   アウトは0と等価です。

   For both POSIX and Windows, an object can appear in *object_list*
   if it is

   * 読み取り可能な "Connection" オブジェクト;

   * 接続された読み取り可能な "socket.socket" オブジェクト; または

   * "Process" オブジェクトの "sentinel" 属性。

   読み取ることのできるデータがある場合、あるいは相手側の端が閉じられ
   ている場合、コネクションまたはソケットオブジェクトは準備ができてい
   ます。

   **POSIX**: "wait(object_list, timeout)" almost equivalent
   "select.select(object_list, [], [], timeout)".  The difference is
   that, if "select.select()" is interrupted by a signal, it can raise
   "OSError" with an error number of "EINTR", whereas "wait()" will
   not.

   **Windows**: An item in *object_list* must either be an integer
   handle which is waitable (according to the definition used by the
   documentation of the Win32 function "WaitForMultipleObjects()") or
   it can be an object with a "fileno()" method which returns a socket
   handle or pipe handle.  (Note that pipe handles and socket handles
   are **not** waitable handles.)

   Added in version 3.3.

**例**

次のサーバーコードは認証キーとして "'secret password'" を使用するリス
ナーを作成します。このサーバーはコネクションを待ってクライアントへデー
タを送信します:

   from multiprocessing.connection import Listener
   from array import array

   address = ('localhost', 6000)     # family is deduced to be 'AF_INET'

   with Listener(address, authkey=b'secret password') as listener:
       with listener.accept() as conn:
           print('connection accepted from', listener.last_accepted)

           conn.send([2.25, None, 'junk', float])

           conn.send_bytes(b'hello')

           conn.send_bytes(array('i', [42, 1729]))

次のコードはサーバーへ接続して、サーバーからデータを受信します:

   from multiprocessing.connection import Client
   from array import array

   address = ('localhost', 6000)

   with Client(address, authkey=b'secret password') as conn:
       print(conn.recv())                  # => [2.25, None, 'junk', float]

       print(conn.recv_bytes())            # => 'hello'

       arr = array('i', [0, 0, 0, 0, 0])
       print(conn.recv_bytes_into(arr))    # => 8
       print(arr)                          # => array('i', [42, 1729, 0, 0, 0])

次のコードは "wait()" を使って複数のプロセスからのメッセージを同時に待
ちます:

   import time, random
   from multiprocessing import Process, Pipe, current_process
   from multiprocessing.connection import wait

   def foo(w):
       for i in range(10):
           w.send((i, current_process().name))
       w.close()

   if __name__ == '__main__':
       readers = []

       for i in range(4):
           r, w = Pipe(duplex=False)
           readers.append(r)
           p = Process(target=foo, args=(w,))
           p.start()
           # We close the writable end of the pipe now to be sure that
           # p is the only process which owns a handle for it.  This
           # ensures that when p closes its handle for the writable end,
           # wait() will promptly report the readable end as being ready.
           w.close()

       while readers:
           for r in wait(readers):
               try:
                   msg = r.recv()
               except EOFError:
                   readers.remove(r)
               else:
                   print(msg)


アドレスフォーマット
~~~~~~~~~~~~~~~~~~~~

* "'AF_INET'" アドレスは "(hostname, port)" のタプルになります。
  *hostname* は文字列で *port* は整数です。

* "'AF_UNIX'" アドレスはファイルシステム上のファイル名の文字列です。

* "'AF_PIPE'" アドレスは "r'\\.\pipe\*PipeName*'" という形式の文字列で
  す。 *ServerName* という名前のリモートコンピューター上の名前付きパイ
  プに接続するために "Client()" を使用するには、代わりに
  "r'\\*ServerName*\pipe\*PipeName*'" 形式のアドレスを使用する必要があ
  ります。

デフォルトでは、2つのバックスラッシュで始まる文字列は "'AF_UNIX'" より
も "'AF_PIPE'" として推測されることに注意してください。


認証キー
--------

"Connection.recv" を使用するとき、データは自動的に unpickle されて受信
します。 信頼できない接続元からのデータを unpickle することはセキュリ
ティリスクがあります。 そのため "Listener" や "Client()" はダイジェス
ト認証を提供するために "hmac" モジュールを使用します。

認証キーはパスワードとして見なされるバイト文字列です。コネクションが確
立すると、双方の終点で正しい接続先であることを証明するために 知ってい
るお互いの認証キーを要求します。(双方の終点が同じキーを使用して通信し
ようとしても、コネクション上でそのキーを送信することは **できません**
。)

認証が要求されているにもかかわらず認証キーが指定されていない場合
"current_process().authkey" の返す値が使用されます。 (詳細は "Process"
を参照してください。) この値はカレントプロセスを作成する "Process" オ
ブジェクトによって自動的に継承されます。 これは(デフォルトでは)複数プ
ロセスのプログラムの全プロセスが相互にコネクションを 確立するときに使
用される1つの認証キーを共有することを意味します。

適当な認証キーを "os.urandom()" を使用して生成することもできます。


ログ記録
--------

ロギングのためにいくつかの機能が利用可能です。しかし "logging" パッケ
ージは、 (ハンドラー種別に依存して)違うプロセスからのメッセージがごち
ゃ混ぜになるので、プロセスの共有ロックを使用しないことに注意してくださ
い。

multiprocessing.get_logger()

   "multiprocessing" が使用するロガーを返します。必要に応じて新たなロ
   ガーを作成します。

   When first created the logger has level "logging.NOTSET" and no
   default handler. Messages sent to this logger will not by default
   propagate to the root logger.

   Windows 上では子プロセスが親プロセスのロガーレベルを継承しないこと
   に注意してください。さらにその他のロガーのカスタマイズ内容もすべて
   継承されません。

multiprocessing.log_to_stderr(level=None)

   この関数は "get_logger()" に対する呼び出しを実行しますが、
   get_logger によって作成されるロガーを返すことに加えて、
   "'[%(levelname)s/%(processName)s] %(message)s'" のフォーマットを使
   用して "sys.stderr" へ出力を送るハンドラーを追加します。"level" 引
   数を渡すことによってロガーの "levelname" を変更できます。

以下にロギングを有効にした例を紹介します:

   >>> import multiprocessing, logging
   >>> logger = multiprocessing.log_to_stderr()
   >>> logger.setLevel(logging.INFO)
   >>> logger.warning('doomed')
   [WARNING/MainProcess] doomed
   >>> m = multiprocessing.Manager()
   [INFO/SyncManager-...] child process calling self.run()
   [INFO/SyncManager-...] created temp directory /.../pymp-...
   [INFO/SyncManager-...] manager serving at '/.../listener-...'
   >>> del m
   [INFO/MainProcess] sending shutdown message to manager
   [INFO/SyncManager-...] manager exiting with exitcode 0

完全なロギングレベルの表については "logging" モジュールを参照してくだ
さい。


"multiprocessing.dummy" モジュール
----------------------------------

"multiprocessing.dummy" は "multiprocessing" の API を複製しますが
"threading" モジュールのラッパーでしかありません。

In particular, the "Pool" function provided by "multiprocessing.dummy"
returns an instance of "ThreadPool", which is a subclass of "Pool"
that supports all the same method calls but uses a pool of worker
threads rather than worker processes.

class multiprocessing.pool.ThreadPool([processes[, initializer[, initargs]]])

   A thread pool object which controls a pool of worker threads to
   which jobs can be submitted.  "ThreadPool" instances are fully
   interface compatible with "Pool" instances, and their resources
   must also be properly managed, either by using the pool as a
   context manager or by calling "close()" and "terminate()" manually.

   *processes* is the number of worker threads to use.  If *processes*
   is "None" then the number returned by "os.cpu_count()" is used.

   *initializer* が "None" ではない場合、各ワーカープロセスは開始時に
   "initializer(*initargs)" を呼び出します。

   Unlike "Pool", *maxtasksperchild* and *context* cannot be provided.

   注釈:

     A "ThreadPool" shares the same interface as "Pool", which is
     designed around a pool of processes and predates the introduction
     of the "concurrent.futures" module.  As such, it inherits some
     operations that don't make sense for a pool backed by threads,
     and it has its own type for representing the status of
     asynchronous jobs, "AsyncResult", that is not understood by any
     other libraries.Users should generally prefer to use
     "concurrent.futures.ThreadPoolExecutor", which has a simpler
     interface that was designed around threads from the start, and
     which returns "concurrent.futures.Future" instances that are
     compatible with many other libraries, including "asyncio".


プログラミングガイドライン
==========================

"multiprocessing" を使用するときに守るべき一定のガイドラインとイディオ
ムを挙げます。


すべての開始方式について
------------------------

以下はすべての開始方式に当てはまります。

共有状態を避ける

   できるだけプロセス間で巨大なデータを移動することは避けるようにすべ
   きです。

   プロセス間の通信には、"threading" モジュールの低レベルな同期プリミ
   ティブを使うのではなく、キューやパイプを使うのが良いでしょう。

pickle 化の可能性

   プロキシのメソッドへの引数は、 pickle 化できるものにしてください。

プロキシのスレッドセーフ性

   1 つのプロキシオブジェクトは、ロックで保護しないかぎり、2 つ以上の
   スレッドから使用してはいけません。

   (異なるプロセスで *同じ* プロキシを使用することは問題ではありません
   。)

ゾンビプロセスを join する

   On POSIX when a process finishes but has not been joined it becomes
   a zombie. There should never be very many because each time a new
   process starts (or "active_children()" is called) all completed
   processes which have not yet been joined will be joined.  Also
   calling a finished process's "Process.is_alive" will join the
   process.  Even so it is probably good practice to explicitly join
   all the processes that you start.

pickle/unpickle より継承する方が良い

   開始方式に *spawn* あるいは *forkserver* を使用している場合、
   "multiprocessing" から多くの型を pickle 化する必要があるため子プロ
   セスはそれらを使うことができます。しかし、一般にパイプやキューを使
   用して共有オブジェクトを他のプロセスに送信することは避けるべきです
   。代わりに、共有リソースにアクセスする必要のあるプロセスは上位プロ
   セスからそれらを継承するようにすべきです。

プロセスの強制終了を避ける

   あるプロセスを停止するために "Process.terminate" メソッドを使用する
   と、そのプロセスが現在使用されている (ロック、セマフォ、パイプやキ
   ューのような) 共有リソースを破壊したり他のプロセスから利用できない
   状態を引き起こし易いです。

   そのため、共有リソースを使用しないプロセスでのみ
   "Process.terminate" を使用することを考慮することがおそらく最善の方
   法です。

キューを使用するプロセスを join する

   キューに要素を追加するプロセスは、すべてのバッファーされた要素が
   "feeder" スレッドによって下位層のパイプに対してフィードされるまで終
   了を待つということを覚えておいてください。 (子プロセスはこの動作を
   避けるためにキューの "Queue.cancel_join_thread" メソッドを呼ぶこと
   ができます。)

   これはキューを使用するときに、キューに追加されたすべての要素が最終
   的にそのプロセスが join される前に削除されていることを確認する必要
   があることを意味します。そうしないと、そのキューに要素が追加したプ
   ロセスの終了を保証できません。デーモンではないプロセスは自動的に
   join されることも覚えておいてください。

   次の例はデッドロックを引き起こします:

      from multiprocessing import Process, Queue

      def f(q):
          q.put('X' * 1000000)

      if __name__ == '__main__':
          queue = Queue()
          p = Process(target=f, args=(queue,))
          p.start()
          p.join()                    # this deadlocks
          obj = queue.get()

   修正するには最後の2行を入れ替えます(または単純に "p.join()" の行を
   削除します)。

明示的に子プロセスへリソースを渡す

   On POSIX using the *fork* start method, a child process can make
   use of a shared resource created in a parent process using a global
   resource.  However, it is better to pass the object as an argument
   to the constructor for the child process.

   Windows や他の開始方式と (将来的にでも) 互換性のあるコードを書く場
   合は別として、これは子プロセスが実行中である限りは親プロセス内でオ
   ブジェクトがガベージコレクトされないことも保証します。これは親プロ
   セス内でオブジェクトがガベージコレクトされたときに一部のリソースが
   開放されてしまう場合に重要かもしれません。

   そのため、例えば

      from multiprocessing import Process, Lock

      def f():
          ... do something using "lock" ...

      if __name__ == '__main__':
          lock = Lock()
          for i in range(10):
              Process(target=f).start()

   は、次のように書き直すべきです

      from multiprocessing import Process, Lock

      def f(l):
          ... do something using "l" ...

      if __name__ == '__main__':
          lock = Lock()
          for i in range(10):
              Process(target=f, args=(lock,)).start()

"sys.stdin" を file-like オブジェクトに置き換えることに注意する

   "multiprocessing" は元々無条件に:

      os.close(sys.stdin.fileno())

   を "multiprocessing.Process._bootstrap()" メソッドの中で呼び出して
   いました --- これはプロセス内プロセス (processes-in-processes) で問
   題が起こしてしまいます。そこで、これは以下のように変更されました:

      sys.stdin.close()
      sys.stdin = open(os.open(os.devnull, os.O_RDONLY), closefd=False)

   これによってプロセス同士が衝突して bad file descripter エラーを起こ
   すという根本的な問題は解決しましたが、アプリケーションの出力バッフ
   ァーを "sys.stdin()" から "file-like オブジェクト" に置き換えるとい
   う潜在的危険を持ち込んでしまいました。危険というのは、複数のプロセ
   スが file-like オブジェクトの "close()" を呼び出すと、オブジェクト
   に同じデータが何度もフラッシュされ、破損してしまう可能性がある、と
   いうものです。

   もし file-like オブジェクトを書いて独自のキャッシュを実装するなら、
   キャッシュするときに常に pid を記録しておき、pid が変わったらキュッ
   シュを捨てることで、フォークセーフにできます。例:

      @property
      def cache(self):
          pid = os.getpid()
          if pid != self._pid:
              self._pid = pid
              self._cache = []
          return self._cache

   より詳しい情報は bpo-5155 、 bpo-5313 、 bpo-5331 を見てください


開始方式が *spawn* および *forkserver* の場合
---------------------------------------------

There are a few extra restrictions which don't apply to the *fork*
start method.

さらなる pickle 化の可能性

   "Process.__init__()" へのすべての引数は pickle 化できることを確認し
   てください。また "Process" をサブクラス化する場合、そのインスタンス
   が "Process.start" メソッドが呼ばれたときに pickle 化できるようにし
   てください。

グローバル変数

   子プロセスで実行されるコードがグローバル変数にアクセスしようとする
   場合、子プロセスが見るその値は "Process.start" が呼ばれたときの親プ
   ロセスの値と同じではない可能性があります。

   しかし、単にモジュールレベルの定数であるグローバル変数なら問題には
   なりません。

メインモジュールの安全なインポート

   Make sure that the main module can be safely imported by a new
   Python interpreter without causing unintended side effects (such as
   starting a new process).

   例えば、開始方式に *spawn* あるいは *forkserver* を使用した場合に以
   下のモジュールを実行すると "RuntimeError" で失敗します:

      from multiprocessing import Process

      def foo():
          print('hello')

      p = Process(target=foo)
      p.start()

   代わりに、次のように "if __name__ == '__main__':" を使用してプログ
   ラムの "エントリポイント" を保護すべきです:

      from multiprocessing import Process, freeze_support, set_start_method

      def foo():
          print('hello')

      if __name__ == '__main__':
          freeze_support()
          set_start_method('spawn')
          p = Process(target=foo)
          p.start()

   (プログラムをフリーズせずに通常通り実行するなら "freeze_support()"
   行は取り除けます。)

   これは新たに生成された Python インタープリターがそのモジュールを安
   全にインポートして、モジュールの "foo()" 関数を実行します。

   プールまたはマネージャーがメインモジュールで作成される場合に似たよ
   うな制限が適用されます。


使用例
======

カスタマイズされたマネージャーやプロキシの作成方法と使用方法を紹介しま
す:

   from multiprocessing import freeze_support
   from multiprocessing.managers import BaseManager, BaseProxy
   import operator

   ##

   class Foo:
       def f(self):
           print('you called Foo.f()')
       def g(self):
           print('you called Foo.g()')
       def _h(self):
           print('you called Foo._h()')

   # A simple generator function
   def baz():
       for i in range(10):
           yield i*i

   # Proxy type for generator objects
   class GeneratorProxy(BaseProxy):
       _exposed_ = ['__next__']
       def __iter__(self):
           return self
       def __next__(self):
           return self._callmethod('__next__')

   # Function to return the operator module
   def get_operator_module():
       return operator

   ##

   class MyManager(BaseManager):
       pass

   # register the Foo class; make `f()` and `g()` accessible via proxy
   MyManager.register('Foo1', Foo)

   # register the Foo class; make `g()` and `_h()` accessible via proxy
   MyManager.register('Foo2', Foo, exposed=('g', '_h'))

   # register the generator function baz; use `GeneratorProxy` to make proxies
   MyManager.register('baz', baz, proxytype=GeneratorProxy)

   # register get_operator_module(); make public functions accessible via proxy
   MyManager.register('operator', get_operator_module)

   ##

   def test():
       manager = MyManager()
       manager.start()

       print('-' * 20)

       f1 = manager.Foo1()
       f1.f()
       f1.g()
       assert not hasattr(f1, '_h')
       assert sorted(f1._exposed_) == sorted(['f', 'g'])

       print('-' * 20)

       f2 = manager.Foo2()
       f2.g()
       f2._h()
       assert not hasattr(f2, 'f')
       assert sorted(f2._exposed_) == sorted(['g', '_h'])

       print('-' * 20)

       it = manager.baz()
       for i in it:
           print('<%d>' % i, end=' ')
       print()

       print('-' * 20)

       op = manager.operator()
       print('op.add(23, 45) =', op.add(23, 45))
       print('op.pow(2, 94) =', op.pow(2, 94))
       print('op._exposed_ =', op._exposed_)

   ##

   if __name__ == '__main__':
       freeze_support()
       test()

"Pool" を使用する例です:

   import multiprocessing
   import time
   import random
   import sys

   #
   # Functions used by test code
   #

   def calculate(func, args):
       result = func(*args)
       return '%s says that %s%s = %s' % (
           multiprocessing.current_process().name,
           func.__name__, args, result
           )

   def calculatestar(args):
       return calculate(*args)

   def mul(a, b):
       time.sleep(0.5 * random.random())
       return a * b

   def plus(a, b):
       time.sleep(0.5 * random.random())
       return a + b

   def f(x):
       return 1.0 / (x - 5.0)

   def pow3(x):
       return x ** 3

   def noop(x):
       pass

   #
   # Test code
   #

   def test():
       PROCESSES = 4
       print('Creating pool with %d processes\n' % PROCESSES)

       with multiprocessing.Pool(PROCESSES) as pool:
           #
           # Tests
           #

           TASKS = [(mul, (i, 7)) for i in range(10)] + \
                   [(plus, (i, 8)) for i in range(10)]

           results = [pool.apply_async(calculate, t) for t in TASKS]
           imap_it = pool.imap(calculatestar, TASKS)
           imap_unordered_it = pool.imap_unordered(calculatestar, TASKS)

           print('Ordered results using pool.apply_async():')
           for r in results:
               print('\t', r.get())
           print()

           print('Ordered results using pool.imap():')
           for x in imap_it:
               print('\t', x)
           print()

           print('Unordered results using pool.imap_unordered():')
           for x in imap_unordered_it:
               print('\t', x)
           print()

           print('Ordered results using pool.map() --- will block till complete:')
           for x in pool.map(calculatestar, TASKS):
               print('\t', x)
           print()

           #
           # Test error handling
           #

           print('Testing error handling:')

           try:
               print(pool.apply(f, (5,)))
           except ZeroDivisionError:
               print('\tGot ZeroDivisionError as expected from pool.apply()')
           else:
               raise AssertionError('expected ZeroDivisionError')

           try:
               print(pool.map(f, list(range(10))))
           except ZeroDivisionError:
               print('\tGot ZeroDivisionError as expected from pool.map()')
           else:
               raise AssertionError('expected ZeroDivisionError')

           try:
               print(list(pool.imap(f, list(range(10)))))
           except ZeroDivisionError:
               print('\tGot ZeroDivisionError as expected from list(pool.imap())')
           else:
               raise AssertionError('expected ZeroDivisionError')

           it = pool.imap(f, list(range(10)))
           for i in range(10):
               try:
                   x = next(it)
               except ZeroDivisionError:
                   if i == 5:
                       pass
               except StopIteration:
                   break
               else:
                   if i == 5:
                       raise AssertionError('expected ZeroDivisionError')

           assert i == 9
           print('\tGot ZeroDivisionError as expected from IMapIterator.next()')
           print()

           #
           # Testing timeouts
           #

           print('Testing ApplyResult.get() with timeout:', end=' ')
           res = pool.apply_async(calculate, TASKS[0])
           while 1:
               sys.stdout.flush()
               try:
                   sys.stdout.write('\n\t%s' % res.get(0.02))
                   break
               except multiprocessing.TimeoutError:
                   sys.stdout.write('.')
           print()
           print()

           print('Testing IMapIterator.next() with timeout:', end=' ')
           it = pool.imap(calculatestar, TASKS)
           while 1:
               sys.stdout.flush()
               try:
                   sys.stdout.write('\n\t%s' % it.next(0.02))
               except StopIteration:
                   break
               except multiprocessing.TimeoutError:
                   sys.stdout.write('.')
           print()
           print()


   if __name__ == '__main__':
       multiprocessing.freeze_support()
       test()

ワーカープロセスのコレクションに対してタスクをフィードしてその結果をま
とめるキューの使い方の例を紹介します:

   import time
   import random

   from multiprocessing import Process, Queue, current_process, freeze_support

   #
   # Function run by worker processes
   #

   def worker(input, output):
       for func, args in iter(input.get, 'STOP'):
           result = calculate(func, args)
           output.put(result)

   #
   # Function used to calculate result
   #

   def calculate(func, args):
       result = func(*args)
       return '%s says that %s%s = %s' % \
           (current_process().name, func.__name__, args, result)

   #
   # Functions referenced by tasks
   #

   def mul(a, b):
       time.sleep(0.5*random.random())
       return a * b

   def plus(a, b):
       time.sleep(0.5*random.random())
       return a + b

   #
   #
   #

   def test():
       NUMBER_OF_PROCESSES = 4
       TASKS1 = [(mul, (i, 7)) for i in range(20)]
       TASKS2 = [(plus, (i, 8)) for i in range(10)]

       # Create queues
       task_queue = Queue()
       done_queue = Queue()

       # Submit tasks
       for task in TASKS1:
           task_queue.put(task)

       # Start worker processes
       for i in range(NUMBER_OF_PROCESSES):
           Process(target=worker, args=(task_queue, done_queue)).start()

       # Get and print results
       print('Unordered results:')
       for i in range(len(TASKS1)):
           print('\t', done_queue.get())

       # Add more tasks using `put()`
       for task in TASKS2:
           task_queue.put(task)

       # Get and print some more results
       for i in range(len(TASKS2)):
           print('\t', done_queue.get())

       # Tell child processes to stop
       for i in range(NUMBER_OF_PROCESSES):
           task_queue.put('STOP')


   if __name__ == '__main__':
       freeze_support()
       test()
