summaryrefslogtreecommitdiffstats
path: root/Lib/multiprocessing/pool.py
Commit message (Collapse)AuthorAgeFilesLines
* Fix typo in exception message in `multiprocessing.pool` (#99900)Arne de Laat2022-11-301-1/+1
|
* GH-83658: make multiprocessing.Pool raise an exception if maxtasksperchild ↵Irit Katriel2022-06-171-0/+3
| | | | | is not None or a positive int (GH-93364) Closes #83658.
* bpo-40443: Remove unused imports in stdlib (GH-19815)Victor Stinner2020-05-011-1/+0
|
* bpo-39481: PEP 585 for a variety of modules (GH-19423)Batuhan Taşkaya2020-04-101-0/+3
| | | | | | | | | | - concurrent.futures - ctypes - http.cookies - multiprocessing - queue - tempfile - unittest.case - urllib.parse
* bpo-39360: Ensure all workers exit when finalizing a multiprocessing Pool ↵Batuhan Taşkaya2020-03-151-2/+5
| | | | | | | | | (GH-19009) When the pull is not used via the context manager or terminate() is called, there is a system in multiprocessing.util that handles finalization of all pools via an atexit handler (the Finalize) class. This class registers the _terminate_pool handler in the registry of finalizers of the module, and that registry is called on interpreter exit via _exit_function. The problem is that the "happy" path with the context manager or manual call to finalize() does some extra steps that _terminate_pool does not. The step that is not executed when the atexit() handler calls _terminate_pool is pinging the _change_notifier queue to unblock the maintenance threads. This commit moves the notification to the _terminate_pool function so is called from both code paths. Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>
* bpo-37116: Use PEP 570 syntax for positional-only parameters. (GH-13700)Serhiy Storchaka2019-06-011-1/+1
|
* bpo-35493: Use Process.sentinel instead of sleeping for polling worker ↵Pablo Galindo2019-03-161-11/+77
| | | | | | | | | | | | | | | | | | | | status in multiprocessing.Pool (#11488) * bpo-35493: Use Process.sentinel instead of sleeping for polling worker status in multiprocessing.Pool * Use self-pipe pattern to avoid polling for changes * Refactor some variable names and add comments * Restore timeout and poll * Use reader object only on wait() * Recompute worker sentinels every time * Remove timeout and use change notifier * Refactor some methods to be overloaded by the ThreadPool, document the cache class and fix typos
* bpo-35378: Fix multiprocessing.Pool references (GH-11627)Pablo Galindo2019-02-111-38/+74
| | | | | | | | | Changes in this commit: 1. Use a _strong_ reference between the Pool and associated iterators 2. Rework PR #8450 to eliminate a cycle in the Pool. There is no test in this commit because any test that automatically tests this behaviour needs to eliminate the pool before joining the pool to check that the pool object is garbaged collected/does not hang. But doing this will potentially leak threads and processes (see https://bugs.python.org/issue35413).
* bpo-35424: emit ResourceWarning at multiprocessing.Pool destruction (GH-10974)Victor Stinner2018-12-201-5/+18
| | | | multiprocessing.Pool destructor now emits ResourceWarning if the pool is still running.
* bpo-35491, multiprocessing: replace "RUN" with RUN (GH-11178)Victor Stinner2018-12-161-1/+1
|
* Add multiprocessing.Pool.__repr__() (GH-11137)Victor Stinner2018-12-141-5/+11
| | | | | * Add multiprocessing.Pool.__repr__() to ease debug * RUN, CLOSE and TERMINATE constants values are now strings rather than integer to ease debug
* bpo-35477: multiprocessing.Pool.__enter__() fails if called twice (GH-11134)Victor Stinner2018-12-131-8/+9
| | | | multiprocessing.Pool.__enter__() now fails if the pool is not running: "with pool:" fails if used more than once.
* Revert "bpo-34172: multiprocessing.Pool leaks resources after being deleted ↵Victor Stinner2018-12-061-50/+24
| | | | | (GH-8450)" (GH-10971) This reverts commit 97bfe8d3ebb0a54c8798f57555cb4152f9b2e1d0.
* bpo-19675: Terminate processes if construction of a pool is failing. (GH-5614)Julien Palard2018-11-041-2/+10
|
* bpo-34172: multiprocessing.Pool leaks resources after being deleted (GH-8450)tzickel2018-10-021-24/+50
| | | Fix a reference issue inside multiprocessing.Pool that caused the pool to remain alive if it was deleted without being closed or terminated explicitly.
* bpo-32576: use queue.SimpleQueue in critical places (#5216)Antoine Pitrou2018-01-181-8/+11
| | | | Where a queue may be invoked from a weakref callback, we need to use the reentrant SimpleQueue.
* [Trivial] Remove now redundant assert (#3245)Antoine Pitrou2017-08-301-1/+0
|
* bpo-5001: More-informative multiprocessing error messages (#3079)Allen W. Smith, Ph.D2017-08-291-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Make error message more informative Replace assertions in error-reporting code with more-informative version that doesn't cause confusion over where and what the error is. * Additional clarification + get travis to check * Change from SystemError to TypeError As suggested in PR comment by @pitrou, changing from SystemError; TypeError appears appropriate. * NEWS file installation; ACKS addition (will do my best to justify it by additional work) * Making current AssertionErrors in multiprocessing more informative * Blurb added re multiprocessing managers.py, queues.py cleanup * Further multiprocessing cleanup - went through pool.py * Fix two asserts in multiprocessing/util.py * Most asserts in multiprocessing more informative * Didn't save right version * Further work on multiprocessing error messages * Correct typo * Correct typo v2 * Blasted colon... serves me right for trying to work on two things at once * Simplify NEWS entry * Update 2017-08-18-17-16-38.bpo-5001.gwnthq.rst * Update 2017-08-18-17-16-38.bpo-5001.gwnthq.rst OK, never mind. * Corrected (thanks to pitrou) error messages for notify * Remove extraneous backslash in docstring.
* bpo-29762: More use "raise from None". (#569)Serhiy Storchaka2017-04-051-3/+3
| | | This hides unwanted implementation details from tracebacks.
* bpo-28699: fix abnormal behaviour of pools in multiprocessing.pool (GH-693)Xiang Zhang2017-03-291-24/+55
| | | | | an exception raised at the very first of an iterable would cause pools behave abnormally (swallow the exception or hang)
* bpo-29861: release references to multiprocessing Pool tasks (#743)Antoine Pitrou2017-03-241-1/+6
| | | | | | | | | | * bpo-29861: release references to multiprocessing Pool tasks Release references to tasks, their arguments and their results as soon as they are finished, instead of keeping them alive until another task arrives. * Comments in test
* Issue #23992: multiprocessing: make MapResult not fail-fast upon exception.Charles-François Natali2016-02-101-8/+12
|
* Issue #23051: multiprocessing.Pool methods imap() and imap_unordered() nowSerhiy Storchaka2015-03-131-14/+23
|\ | | | | | | | | handle exceptions raised by an iterator. Patch by Alon Diamant and Davin Potts.
| * Issue #23051: multiprocessing.Pool methods imap() and imap_unordered() nowSerhiy Storchaka2015-03-131-14/+23
| | | | | | | | | | handle exceptions raised by an iterator. Patch by Alon Diamant and Davin Potts.
* | Issue #22033: Reprs of most Python implemened classes now contain actualSerhiy Storchaka2014-07-251-1/+1
| | | | | | | | class name instead of hardcoded one.
* | Issue #21565: multiprocessing: use contex-manager protocol for synchronizationCharles-François Natali2014-05-251-20/+5
|/ | | | primitives.
* Issue #20980: Stop wrapping exception when using ThreadPool.Richard Oudkerk2014-03-231-3/+9
|
* Issue #20976: pyflakes: Remove unused importsVictor Stinner2014-03-201-1/+1
|
* Merge.Richard Oudkerk2013-10-281-5/+9
|\
| * Issue #19425 -- a pickling error should not cause pool to hang.Richard Oudkerk2013-10-281-5/+9
| |
* | Issue #18999: Make multiprocessing use context objects.Richard Oudkerk2013-10-161-5/+7
| | | | | | | | | | This allows different parts of a program to use different methods for starting processes without interfering with each other.
* | Issue #8713: Support alternative start methods in multiprocessing on Unix.Richard Oudkerk2013-08-141-40/+44
| | | | | | | | See http://hg.python.org/sandbox/sbt#spawn
* | Issue #17914: Use os.cpu_count() instead of multiprocessing.cpu_count() whereCharles-François Natali2013-06-281-5/+3
| | | | | | | | applicable.
* | MergeRichard Oudkerk2013-05-061-0/+2
|\ \ | |/
| * Issue #17805: Add AsyncResult alias for ApplyResultRichard Oudkerk2013-05-061-0/+2
| |
* | Issue #13813: Embed stringification of remote traceback in localRichard Oudkerk2013-05-061-0/+25
| | | | | | | | traceback raised when pool task raises an exception.
* | Replace IOError with OSError (#16715)Andrew Svetlov2012-12-251-10/+10
|/
* #16307: Fix multiprocessing.Pool.map_async not calling its callbacksHynek Schlawack2012-10-271-1/+2
| | | | Patch by Janne Karila.
* raise a ValueError instead of an AssertionError when pool is an invalid stateBenjamin Peterson2012-09-251-7/+8
|
* Issue #15064: Implement context manager protocol for multiprocessing typesRichard Oudkerk2012-06-181-0/+6
|
* Issue #15101: Make pool finalizer avoid joining current thread.Richard Oudkerk2012-06-181-3/+6
|\
| * Issue #15101: Make pool finalizer avoid joining current thread.Richard Oudkerk2012-06-181-3/+6
| |
* | Merge fixes for #13854 and #12157.Richard Oudkerk2012-06-071-0/+1
|\ \ | |/
| * Issue #12157: pool.map() does not handle empty iterable correctlyRichard Oudkerk2012-06-061-0/+1
| | | | | | | | Initial patch by mouad
* | Issue #12091: simplify ApplyResult and MapResult with threading.EventRichard Oudkerk2012-05-251-30/+9
| | | | | | | | Patch by Charles-François Natali
* | Mark multiprocessing files with "Licensed to PSF under a Contributor Agreement"Richard Oudkerk2012-04-301-26/+1
| | | | | | | | instead of BSD licence.
* | Issue #12708: Add starmap() and starmap_async() methods (similar to ↵Antoine Pitrou2011-12-211-2/+30
|/ | | | | | itertools.starmap()) to multiprocessing.Pool. Patch by Hynek Schlawack.
* Closes #13258: Use callable() built-in in the standard library.Florent Xicluna2011-10-281-1/+1
|
* Issue #10332: multiprocessing: fix a race condition when a Pool is closedCharles-François Natali2011-10-241-1/+5
| | | | before all tasks have completed.
* Issue #12285: multiprocessing.Pool() raises a ValueError if the number ofVictor Stinner2011-06-201-0/+2
| | | | processes if negative or null.
generated by cgit v0.12 at 2024-11-14 22:34:27 (GMT)