[issue10845] test_multiprocessing failure under Windows

Roundup Robot added the comment: New changeset 5d88c1d413b9 by Nick Coghlan in branch '2.7': Close #10128: don't rerun __main__.py in multiprocessing https://hg.python.org/cpython/rev/5d88c1d413b9 -- nosy: +python-dev ___ Python tracker

[issue10845] test_multiprocessing failure under Windows

Changes by Gabi Davar : -- nosy: +Gabi.Davar ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: Yeah, the broader issue with multiprocessing, Windows and state held in the main module is covered by PEP 395, so there's no need to double up by keeping this open. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed _

[issue10845] test_multiprocessing failure under Windows

Kristian Vlaardingerbroek added the comment: This has been committed a while ago, can this issue be closed? -- nosy: +Kristian.Vlaardingerbroek ___ Python tracker ___ _

[issue10845] test_multiprocessing failure under Windows

Changes by Georg Brandl : -- priority: release blocker -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: Committed for 3.2 in r88247. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10845] test_multiprocessing failure under Windows

Georg Brandl added the comment: Looks like Antoine agreed, so this should be fine to go in. -- ___ Python tracker ___ ___ Python-bugs

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: To answer Antoine's question directly: With the patch, it works just as well as multiprocessing on Windows currently does if the objects marshalled between parent and child refer to classes defined inside a "if __name__ == '__main__':" clause in the main module

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: __main__.py files aren't like ordinary modules - they should *not* be defining classes or anything like that. Instead, they should be treated as if the entire file was implicitly inside an "if __name__ == '__main__':" clause - when "imported" they don't do anyt

[issue10845] test_multiprocessing failure under Windows

Antoine Pitrou added the comment: > (Replaced patch file to fix a typo in a comment) Does that patch still work if the objects marshalled between parent and child refer to classes living in the __main__.py module? -- ___ Python tracker

[issue10845] test_multiprocessing failure under Windows

Georg Brandl added the comment: With issue10845_mitigation.diff applied, Antoine's patch is no longer necessary? -- ___ Python tracker ___ __

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: Georg, it would be very good to have this fix in for RC2. Otherwise any use of multiprocessing in conjunction with zipfile, package or directory execution will fail on Windows in 3.2. -- assignee: -> georg.brandl priority: critical -> release blocker

[issue10845] test_multiprocessing failure under Windows

Changes by Nick Coghlan : Removed file: http://bugs.python.org/file20601/issue10845_mitigation.diff ___ Python tracker ___ ___ Python-bugs-lis

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: (Replaced patch file to fix a typo in a comment) -- Added file: http://bugs.python.org/file20603/issue10845_mitigation.diff ___ Python tracker __

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: "Useless" is a rather strong word. Every change we've made to the import system (or, more accurately, the main module identification system) has been backed up with decent use cases - nearly all of the subsequent problems can be traced back to the information t

[issue10845] test_multiprocessing failure under Windows

Jesse Noller added the comment: I'm fine with that tweak antoine -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue10845] test_multiprocessing failure under Windows

Antoine Pitrou added the comment: Actually, forget that (!). The following patch seems to work: Index: Lib/multiprocessing/forking.py === --- Lib/multiprocessing/forking.py (révision 88224) +++ Lib/multiprocessing/forking.py

[issue10845] test_multiprocessing failure under Windows

Antoine Pitrou added the comment: Nick, a more problematic issue is that __main__ is always called __main__, regardless of whether it is actually imported as the real "main module" or through a regular import. This means that it is impossible to discriminate between both uses by using "if __n

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: There isn't really much "-m test" can do to flag this - multiprocessing is making assumptions about the meaning of __file__ that may be flat out invalid when -m is used to execute the main module. Fixing that properly is going to require a PEP so the interprete

[issue10845] test_multiprocessing failure under Windows

Changes by Brett Cannon : -- priority: normal -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10845] test_multiprocessing failure under Windows

Terry J. Reedy added the comment: On xp, changing from -m test to -m test.regrtest removed the extra craziness during and after the test run that I reported on pydev. I think making at least a tempory fix to whatever -m test runs should be a release blocker so only individual tests and not th

[issue10845] test_multiprocessing failure under Windows

Nick Coghlan added the comment: I'm curious as to the results you get running "python -m test.__main__" and "python Lib/test/__main__.py" as well. I suspect both will fail. Looking at the forking.py code, I think multiprocessing makes some assumptions that are flat out invalid in the presence

[issue10845] test_multiprocessing failure under Windows

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue10845] test_multiprocessing failure under Windows

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue10845] test_multiprocessing failure under Windows

Antoine Pitrou added the comment: (I guess this means that multiprocessing under Windows is not compatible with execution of a package through a __main__.py file...) -- ___ Python tracker

[issue10845] test_multiprocessing failure under Windows

Antoine Pitrou added the comment: Actually, it only happens if I use "-m test". If I use "-m test.regrtest" or "Lib/test/regrtest.py" instead, it works fine. -- nosy: +michael.foord, ncoghlan ___ Python tracker _

[issue10845] test_multiprocessing failure under Windows

Changes by Antoine Pitrou : -- nosy: +brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue10845] test_multiprocessing failure under Windows

New submission from Antoine Pitrou : This is under a Windows 7 VM. I don't understand what the assertion means: Z:\>__svn__\PCbuild\amd64\python_d.exe -m test -v test_multiprocessing == CPython 3.2b2+ (py3k, Jan 6 2011, 10:56:48) [MSC v.1500 64 bit (AMD64)] == Windows-7-6.1.7600 little-endian