[issue9122] Problems with multiprocessing, Python embedding and Windows
Changes by Davin Potts pyt...@discontinuity.net: -- resolution: - out of date stage: - resolved status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
Davin Potts added the comment: Closing on the basis that: 1. Richard provided a proposed workaround but did not receive a response from the OP in 1.5 years. 2. Issues encountered by the OP may have been addressed in part by changes in the way import works in the past 4.5 years. 3. This issue has been effectively pending (though not formally marked as such) for more than a year without further information being received from the OP. -- nosy: +davin status: open - pending type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
Mark Lawrence added the comment: Can this be closed as out of date? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
Richard Oudkerk added the comment: We don't do non-security updates on Python 2.6 anymore. As a workaround you might be able to do something like import sys, multiprocessing sys.frozen = True# or multiprocessing.forking.WINEXE = True ... if __name__ == '__main__': multiprocessing.freeze_support() ... (I am not familiar with using Cython.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
Changes by Richard Oudkerk shibt...@gmail.com: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9122] Problems with multiprocessing, Python embedding and Windows
New submission from Alexander Myodov amyo...@gmail.com: Hello, I am using Python 2.6.5 and Cython (to embed the Python interpreter) to create a simple launcher.exe launcher which then imports and uses the remaining logic from the other modules, conveniently stored in a single modules.zip file (i.e. importing from inside zip file). Such setup causes some issues when it comes to the multiprocessing. First of all, the __main__ module is built as a binary (via Cython-mingw), but the stuff like freeze is not used. In multiprocessing/forking.py, when it comes to determination of the primary path, there is a WINEXE variable which affects the further processing. In its assignment, getattr(sys, 'frozen', False) obviously results in False, causing the WINEXE variable be False too (though in my case it is obviously wrong, the stuff like imp.is_builtin(__main__) shows that the main module is indeed builtin). This is the first problem which probably could be solved by adding an additional check for something like imp.is_builtin(__main__) to WINEXE assignment. Further, as the WINEXE is wrongly False, it causes the if not WINEXE: branch to be processed, and adds the 'main_path' to the data, containing the name of the .exe file. On the forked side, d['main_path'] is received and parsed, and the name of the .exe file is split out of its extension, and such name is attempted to be imported, using imp.find_module/imp.load_module. The import fails, as there is indeed no such files wildly lying around in the installation; on the other hand, to get a quick fix of the problem, I thought of adding the appropriate launcher.py(.pyo/.pyc) files into the modules.zip, so that they still could be externally imported by the launcher name, even though it is already builtin under the __main__ name; but the second problem is that the imp.find_module/imp.load_module functions do not find the module inside the zip files, like the import statement does. -- components: Extension Modules, Windows messages: 108953 nosy: honeyman priority: normal severity: normal status: open title: Problems with multiprocessing, Python embedding and Windows versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
