@@ -2661,6 +2661,46 @@ The :mod:`multiprocessing.dummy` module
2661
2661
:mod: `multiprocessing.dummy ` replicates the API of :mod: `multiprocessing ` but is
2662
2662
no more than a wrapper around the :mod: `threading ` module.
2663
2663
2664
+ .. currentmodule :: multiprocessing.pool
2665
+
2666
+ In particular, the ``Pool `` function provided by :mod: `multiprocessing.dummy `
2667
+ returns an instance of :class: `ThreadPool `, which is a subclass of
2668
+ :class: `Pool ` that supports all the same method calls but uses a pool of
2669
+ worker threads rather than worker processes.
2670
+
2671
+
2672
+ .. class :: ThreadPool([processes[, initializer[, initargs]]])
2673
+
2674
+ A thread pool object which controls a pool of worker threads to which jobs
2675
+ can be submitted. :class: `ThreadPool ` instances are fully interface
2676
+ compatible with :class: `Pool ` instances, and their resources must also be
2677
+ properly managed, either by using the pool as a context manager or by
2678
+ calling :meth: `~multiprocessing.pool.Pool.close ` and
2679
+ :meth: `~multiprocessing.pool.Pool.terminate ` manually.
2680
+
2681
+ *processes * is the number of worker threads to use. If *processes * is
2682
+ ``None `` then the number returned by :func: `os.cpu_count ` is used.
2683
+
2684
+ If *initializer * is not ``None `` then each worker process will call
2685
+ ``initializer(*initargs) `` when it starts.
2686
+
2687
+ Unlike :class: `Pool `, *maxtasksperchild * and *context * cannot be provided.
2688
+
2689
+ .. note ::
2690
+
2691
+ A :class: `ThreadPool ` shares the same interface as :class: `Pool `, which
2692
+ is designed around a pool of processes and predates the introduction of
2693
+ the :class: `concurrent.futures ` module. As such, it inherits some
2694
+ operations that don't make sense for a pool backed by threads, and it
2695
+ has its own type for representing the status of asynchronous jobs,
2696
+ :class: `AsyncResult `, that is not understood by any other libraries.
2697
+
2698
+ Users should generally prefer to use
2699
+ :class: `concurrent.futures.ThreadPoolExecutor `, which has a simpler
2700
+ interface that was designed around threads from the start, and which
2701
+ returns :class: `concurrent.futures.Future ` instances that are
2702
+ compatible with many other libraries, including :mod: `asyncio `.
2703
+
2664
2704
2665
2705
.. _multiprocessing-programming :
2666
2706
0 commit comments