summaryrefslogtreecommitdiff
path: root/Lib/multiprocessing
Commit message (Collapse)AuthorAgeFilesLines
* 00169-avoid-implicit-usage-of-md5-in-multiprocessing.patchFedora Python maintainers2020-09-291-2/+10
| | | | | | | | | 00169 # Use SHA-256 rather than implicitly using MD5 within the challenge handling in multiprocessing.connection Sent upstream as http://bugs.python.org/issue17258 (rhbz#879695)
* Revert "[2.7] bpo-34172: multiprocessing.Pool leaks resources after being ↵Victor Stinner2018-12-061-37/+19
| | | | | deleted (GH-9686)" (GH-10970) This reverts commit 4a7dd30f5810e8861a3834159a222ab32d5c97d0.
* [2.7] bpo-34172: multiprocessing.Pool leaks resources after being deleted ↵tzickel2018-10-031-19/+37
| | | | | (GH-9686) Fix a reference issue inside multiprocessing.Pool that caused the pool to remain alive if it was deleted without being closed or terminated explicitly.
* [2.7] bpo-34610: Fixed iterator of multiprocessing.managers.DictProxy. ↵Serhiy Storchaka2018-09-221-1/+4
| | | | | | | (GH-9113). (GH-9500) (cherry picked from commit e0e5065daef36dafe10a46eaa8b7800274d73062) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* bpo-31019: Fix multiprocessing.Process.is_alive() (#2875) (#2882)Victor Stinner2017-07-261-2/+8
| | | | | | | multiprocessing.Process.is_alive() now removes the process from the _children set if the process completed. The change prevents leaking "dangling" processes. (cherry picked from commit 2db64823c20538a6cfc6033661fab5711d2d4585)
* [3.6] bpo-30595: Fix multiprocessing.Queue.get(timeout) (#2027) (#2881) (#2883)Victor Stinner2017-07-261-1/+1
| | | | | | | | | | | | | | | | | | | * bpo-30595: Fix multiprocessing.Queue.get(timeout) (#2027) multiprocessing.Queue.get() with a timeout now polls its reader in non-blocking mode if it succeeded to aquire the lock but the acquire took longer than the timeout. Co-Authored-By: Grzegorz Grzywacz <grzgrzgrz3@gmail.com> (cherry picked from commit 1b7863c3b6519c6e134c28cab8b8af0dea43e375) * bpo-30595: Increase test_queue_feeder_donot_stop_onexc() timeout (#2148) _test_multiprocessing.test_queue_feeder_donot_stop_onexc() now uses a timeout of 1 second on Queue.get(), instead of 0.1 second, for slow buildbots. (cherry picked from commit 8f6eeaf21cdf4aea25fdefeec814a1ce07453fe9) (cherry picked from commit e42339d3a08a8fde3349722def85d7a8e49899be)
* [2.7] Clear potential ref cycle between Process and Process target (GH-2470) ↵Antoine Pitrou2017-06-281-0/+3
| | | | | | | | | | | (#2473) * Clear potential ref cycle between Process and Process target Besides Process.join() not being called, this was an indirect cause of bpo-30775. The threading module already does this. * Add issue reference. (cherry picked from commit 79d37ae979a65ada0b2ac820279ccc3b1cd41ba6)
* [2.7] bpo-24484: Avoid race condition in multiprocessing cleanup (GH-2159) ↵Antoine Pitrou2017-06-131-0/+3
| | | | | | | | | | | | | (#2168) * bpo-24484: Avoid race condition in multiprocessing cleanup The finalizer registry can be mutated while inspected by multiprocessing at process exit. * Use test.support.start_threads() * Add Misc/NEWS. (cherry picked from commit 1eb6c0074d17f4fd425cacfdda893d65f5f77f0a)
* [2.7] bpo-30414: multiprocessing.Queue._feed do not break from main loop on ↵Antoine Pitrou2017-05-251-10/+8
| | | | | | | | | | | | | | | | | | exc (GH-1683) (#1817) * bpo-30414: multiprocesing.Queue._feed do not break from main loop on exc Queue background running thread was not handling exceptions correctly. Any exception occurred inside thread (putting unpickable object) cause feeder to finish running. After that every message put into queue is silently ignored. * bpo-30414: multiprocesing.Queue._feed do not break from main loop on exc Queue background running thread was not handling exceptions correctly. Any exception occurred inside thread (putting unpickable object) cause feeder to finish running. After that every message put into queue is silently ignored.. (cherry picked from commit bc50f03db4f58c869b78e98468e374d7e61f1227)
* bpo-26434: Fix multiprocessing grandchilds in a Windows service (GH-1167)Marc Schlaich2017-05-181-1/+2
| | | Patch by Davin with help from Marc.
* bpo-29861: release references to multiprocessing Pool tasks (#743) (#803)Antoine Pitrou2017-03-241-1/+6
| | | | | | | | | | | | | | | | * bpo-29861: release references to multiprocessing Pool tasks (#743) * 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 (cherry picked from commit 8988945cdc27ffa86ba8c624e095b51c459f5154) * Fix Misc/NEWS ?
* Issue #28998: More APIs now support longs as well as ints.Serhiy Storchaka2016-12-273-5/+5
|
* Issue #21201: Improves readability of multiprocessing error message from ↵Davin Potts2016-09-081-1/+1
| | | | server to client for certain exceptions
* Issue #26778: Fixed "a/an/and" typos in code comment and documentation.Serhiy Storchaka2016-04-171-1/+1
|
* Close #10128: don't rerun __main__.py in multiprocessingNick Coghlan2015-11-191-1/+15
| | | | | | | | - backports issue #10845's mitigation of incompatibilities between the multiprocessing module and directory and zipfile execution - Multiprocessing on Windows will now automatically skip rerunning top level __main__.py modules in spawned processes, rather than failing with AssertionError
* Issue #23865: close() methods in multiple modules now are idempotent and moreSerhiy Storchaka2015-04-102-6/+14
| | | | | robust at shutdown. If needs to release multiple resources, they are released even if errors are occured.
* 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 #22853: Fixed a deadlock when use multiprocessing.Queue at import time.Serhiy Storchaka2015-03-061-6/+4
| | | | Patch by Florian Finkernagel and Davin Potts.
* Issue #21849: Fixed xmlrpclib serialization of non-ASCII unicode strings inSerhiy Storchaka2015-02-132-3/+8
| | | | the multiprocessing module.
* Fixed bugs in reprs of CookieJar and multiprocessing.dummy.Value.Serhiy Storchaka2014-07-221-1/+1
|
* do not generate pipe names in the temporary dirBenjamin Peterson2014-04-141-1/+1
|
* Issue #14548: Make multiprocessing finalizers check pid beforeRichard Oudkerk2014-01-231-3/+9
| | | | | running to cope with possibility of gc running just after fork. (Backport from 3.x.)
* Fix handling of SystemExit and exit code. Patch by Brodie Rao.Richard Oudkerk2013-11-171-1/+1
|
* Issue #19425 -- a pickling error should not cause pool to hang.Richard Oudkerk2013-10-281-5/+9
|
* #18705: fix a number of typos. Patch by Févry Thibault.Ezio Melotti2013-08-171-1/+1
|
* Issue #18455: multiprocessing should not retry connect() with same socket.Richard Oudkerk2013-07-151-3/+4
|
* Issue #17261: Ensure multiprocessing's proxies use proper address.Richard Oudkerk2013-07-021-0/+1
|
* Issue #17097: Make multiprocessing ignore EINTR.Richard Oudkerk2013-07-011-1/+8
|
* - Fix typos in the multiprocessing module.doko@ubuntu.com2013-05-151-1/+1
|
* Issue #17805: Add AsyncResult alias for ApplyResultRichard Oudkerk2013-05-061-0/+2
|
* Issue #17555: Fix ForkAwareThreadLock so that size of after forkRichard Oudkerk2013-04-171-1/+4
| | | | registry does not grow exponentially with generation of process.
* Issue #12098: multiprocessing on Windows now starts child processesKristján Valur Jónsson2013-03-192-1/+3
| | | | | using the same sys.flags as the current process. Backport from default branch.
* Issue #17018: Make Process.join() retry if os.waitpid() fails with EINTR.Richard Oudkerk2013-02-261-6/+12
|
* Issue #15881: Fixed atexit hook in multiprocessing.Benjamin Peterson2013-02-021-9/+32
|
* Issue #10527: Remove dead codeRichard Oudkerk2013-01-151-23/+0
|
* issue 10527: fix missing importGiampaolo Rodola'2013-01-031-0/+1
|
* Fix issue 10527: make multiprocessing use poll() instead of select() if ↵Giampaolo Rodola'2012-12-311-0/+21
| | | | available.
* Issue #15646: Prevent equivalent of a fork bomb when using multiprocessingRichard Oudkerk2012-08-141-1/+1
| | | | on Windows without the "if __name__ == '__main__'" idiom.
* Issue #6056: Make multiprocessing use setblocking(True) on the sockets it uses.Richard Oudkerk2012-07-271-0/+5
| | | | Original patch by J Derek Wilson.
* Issue #15101: Make pool finalizer avoid joining current threadRichard Oudkerk2012-06-181-3/+6
|
* Issue #13854: Properly handle non-integer, non-string arg to SystemExitRichard Oudkerk2012-06-061-3/+3
| | | | | Previously multiprocessing only expected int or str. It also wrongly used an exit code of 1 when the argument was a string instead of zero.
* Issue #12157: pool.map() does not handle empty iterable correctlyRichard Oudkerk2012-06-061-0/+1
| | | | Initial patch by mouad
* Issue #14881: Allow normal non-main thread to spawn a dummy processRichard Oudkerk2012-05-251-1/+2
| | | | Fix suggested by Itay Brandes
* Fix for issue 14725 for 2.7 branchRichard Oudkerk2012-05-051-1/+4
|
* Issue #9400: Partial backport of fix for #9244Richard Oudkerk2012-05-021-1/+24
| | | | | | | | | | In multiprocessing, a pool worker process would die if the result/error could not be pickled. This could cause pool methods to hang. In 3.x this was fixed by 0aa8af79359d (which also added an error_callback argument to some methods), but the fix was not back ported.
* Issue #8184: Fix a potential file descriptor leak when aCharles-François Natali2012-02-041-4/+8
| | | | multiprocessing.Connection socket can't be bound.
* Issue #13565: Increase multiprocessing's server socket backlog, to avoidCharles-François Natali2011-12-231-1/+1
| | | | dropped connections in case of simultaneous connection requests.
* Issue #13373: multiprocessing.Queue.get() could sometimes block indefinitelyAntoine Pitrou2011-11-101-1/+5
| | | | when called with a timeout. Patch by Arnaud Ysmal.
* Issue #10332: multiprocessing: fix a race condition when a Pool is closedCharles-François Natali2011-10-241-1/+5
| | | | before all tasks have completed.
* Remove duplication.Ezio Melotti2011-10-191-1/+1
|
View Lorry Controller Status