Issue #6963: Added maxtasksperchild argument to multiprocessing.Pool
diff --git a/Doc/library/multiprocessing.rst b/Doc/library/multiprocessing.rst
index 0782850..7404145 100644
--- a/Doc/library/multiprocessing.rst
+++ b/Doc/library/multiprocessing.rst
@@ -1537,7 +1537,7 @@
One can create a pool of processes which will carry out tasks submitted to it
with the :class:`Pool` class.
-.. class:: multiprocessing.Pool([processes[, initializer[, initargs]]])
+.. class:: multiprocessing.Pool([processes[, initializer[, initargs[, maxtasksperchild]]]])
A process pool object which controls a pool of worker processes to which jobs
can be submitted. It supports asynchronous results with timeouts and
@@ -1548,6 +1548,21 @@
*initializer* is not ``None`` then each worker process will call
``initializer(*initargs)`` when it starts.
+ *maxtasksperchild* is the number of tasks a worker process can complete
+ before it will exit and be replaced with a fresh worker process, to enable
+ unused resources to be freed. The default *maxtasksperchild* is None, which
+ means worker processes will live as long as the pool.
+
+ .. note::
+
+ Worker processes within a :class:`Pool` typically live for the complete
+ duration of the Pool's work queue. A frequent pattern found in other
+ systems (such as Apache, mod_wsgi, etc) to free resources held by
+ workers is to allow a worker within a pool to complete only a set
+ amount of work before being exiting, being cleaned up and a new
+ process spawned to replace the old one. The *maxtasksperchild*
+ argument to the :class:`Pool` exposes this ability to the end user.
+
.. method:: apply(func[, args[, kwds]])
Equivalent of the :func:`apply` built-in function. It blocks till the