Skip to content

Commit 84ebcf2

Browse files
authored
bpo-17140: Document multiprocessing's ThreadPool (GH-23812)
Up until now, the `multiprocessing.pool.ThreadPool` class has gone undocumented, despite being a public class in multiprocessing that is included in `multiprocessing.pool.__all__`.
1 parent b973542 commit 84ebcf2

File tree

2 files changed

+41
-0
lines changed

2 files changed

+41
-0
lines changed

Doc/library/multiprocessing.rst

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2661,6 +2661,46 @@ The :mod:`multiprocessing.dummy` module
26612661
:mod:`multiprocessing.dummy` replicates the API of :mod:`multiprocessing` but is
26622662
no more than a wrapper around the :mod:`threading` module.
26632663

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+
26642704

26652705
.. _multiprocessing-programming:
26662706

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Add documentation for the :class:`multiprocessing.pool.ThreadPool` class.

0 commit comments

Comments
 (0)