This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author larsoner
Recipients Andrew Nelson, Paul Silisteanu, cjrh, larsoner, pablogsal, ralf.gommers, stefanor
Date 2020-04-10.16:31:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586536267.98.0.687204639937.issue38501@roundup.psfhosted.org>
In-reply-to
Content
If that's out of contract, perhaps there should probably a big, visible warning at the top of the multiprocessning docs stating that creating one of these objects requires either using a context manager or ensuring manual `.close()`ing?

1. It either used to be in contract not to close it manually or was wrongly represented, the first Python 2.7 example in the docs (https://docs.python.org/2/library/multiprocessing.html#introduction) is:

from multiprocessing import Pool

def f(x):
    return x*x

if __name__ == '__main__':
    p = Pool(5)
    print(p.map(f, [1, 2, 3]))

So I suspect this (difficult to track down) problem might hit users without more adequate warning.


2. I'm surprised it's actually out of contract when the 3.8 docs state that close will be automatically called:

> close()
>
> Indicate that no more data will be put on this queue by the current process. The background thread will quit once it has flushed all buffered data to the pipe. This is called automatically when the queue is garbage collected.

and

> terminate()
>
> Stops the worker processes immediately without completing outstanding work. When the pool object is garbage collected terminate() will be called immediately.

Or perhaps I misunderstand what this is saying?
History
Date User Action Args
2020-04-10 16:31:08larsonersetrecipients: + larsoner, cjrh, stefanor, ralf.gommers, pablogsal, Andrew Nelson, Paul Silisteanu
2020-04-10 16:31:07larsonersetmessageid: <1586536267.98.0.687204639937.issue38501@roundup.psfhosted.org>
2020-04-10 16:31:07larsonerlinkissue38501 messages
2020-04-10 16:31:07larsonercreate