Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!news-transit.tcx.org.uk!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'test,': 0.04; 'sure.': 0.05; 'imports': 0.07; 'infinite': 0.07; 'python': 0.08; 'scripts': 0.09; '__name__': 0.09; 'loop.': 0.09; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:80.91.229.12': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'received:lo.gmane.org': 0.09; 'scripts,': 0.09; 'spawn': 0.09; 'underlying': 0.09; 'enigma': 0.16; 'guard': 0.16; 'kern': 0.16; 'setuptools': 0.16; 'stub': 0.16; 'wrote:': 0.18; 'lines,': 0.18; 'header:In-Reply-To:1': 0.22; 'versions': 0.23; 'runs': 0.23; 'fine': 0.24; 'code': 0.25; 'module': 0.26; 'windows': 0.26; "i'm": 0.26; 'import': 0.27; 'installing': 0.29; 'interpret': 0.29; 'module.': 0.29; 'problem': 0.29; 'pm,': 0.29; 'again?': 0.30; 'parent': 0.30; 'subject:?': 0.31; 'does': 0.32; 'andrew': 0.32; 'header:User-Agent:1': 0.33; 'header:X-Complaints- To:1': 0.33; 'to:addr:python-list': 0.34; 'anything': 0.34; 'rest': 0.35; 'install': 0.35; 'problem.': 0.36; 'locate': 0.37; 'but': 0.37; 'received:org': 0.38; 'should': 0.39; 'to:addr:python.org': 0.40; 'your': 0.61; 'world': 0.62; 'received:86': 0.63; 'our': 0.64; 'further': 0.64; 'believe': 0.65; 'cause': 0.67; 'subject:this': 0.74; 'guard,': 0.84; 'idiom': 0.84; 'subject:launch': 0.84; 'eco': 0.91 X-Injected-Via-Gmane: http://gmane.org/ To: python-list@python.org From: Robert Kern Subject: Re: Why does this launch an infinite loop of new processes? Date: Thu, 22 Dec 2011 11:24:21 +0000 References: <4EF22CA1.1070200@gmail.com> <4EF233A7.6020907@stoneleaf.us> <4EF23D57.6010305@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gmane-NNTP-Posting-Host: host86-162-155-255.range86-162.btcentralplus.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <4EF23D57.6010305@gmail.com> X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 29 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1324553111 news.xs4all.nl 6967 [2001:888:2000:d::a6]:41928 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:17728 On 12/21/11 8:11 PM, Andrew Berg wrote: > On 12/21/2011 1:29 PM, Ethan Furman wrote: >> Anything that runs at import time should be protected by the `if >> __name__ == '__main__'` idiom as the children will import the __main__ >> module. > So the child imports the parent and runs the spawn code again? That > makes sense. This is a problem with multiprocessing on Windows. Your code would work fine on a UNIX system. The problem is that Windows does not have a proper fork() for multiprocessing to use. Consequently, it has to start a new Python process from scratch and then *import* the main module such that it can properly locate the rest of the code to start. If you do not guard the spawning code with a __main__ test, then this import will cause an infinite loop. Just as a further note on these lines, when older versions of setuptools and distribute install scripts, they generate stub scripts that do not use a __main__ guard, so installing a multiprocessing-using application with setuptools can cause this problem. I believe newer versions of distribute has this problem fixed, but I'm not sure. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco