• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 101,  comments - 57,  trackbacks - 0

            source: http://bugs.python.org/issue5162

            classificationTitle: multiprocessing cannot spawn child from a Windows service  
            Type: behavior Stage: test needed
            Components: Library (Lib) Versions: Python 2.6
            processStatus: open Resolution: 
            Dependencies:   Superseder: 
            Assigned To: jnoller  Nosy List:  jnoller, orlenko (2) 
            Priority:  normal Keywords patch
             
            Created on 2009-02-06 02:00 by orlenko, last changed 2009-03-29 15:44 by jnoller.

            Files
            File name Uploaded Description Edit Remove
            forking-patch  orlenko, 2009-02-06 02:00  Patch of the forking module  
            Messages (1)
            msg81247 - (view) Author: Volodymyr Orlenko (orlenko) Date: 2009-02-06 02:00 
            I think I've found a small bug with multiprocessing package on
            Windows. If you try to start a multiprocessing.Process from a Python-
            based Windows service, the child process will fail to run. When
            running the parent process as a regular Python program, everything
            works as expected.
            I've tracked the problem down to how main_path is prepared in
            multiprocessing.forking.get_preparation_data() (lines 370-377):
            def get_preparation_data(name):
                [...skipped a few lines...]
                if not WINEXE:
                    main_path = getattr(sys.modules['__main__'], '__file__', None)
                    if not main_path and sys.argv[0] not in ('', '-c'):
                        main_path = sys.argv[0]
                    if main_path is not None:
                        if not os.path.isabs(main_path) and \
                                                  process.ORIGINAL_DIR is not
            None:
                            main_path = os.path.join(process.ORIGINAL_DIR,
            main_path)
                        d['main_path'] = os.path.normpath(main_path)
                return d
            When the program is running as a Windows service, but is not packaged
            into a single executable, main_path will become the path to the
            service executable (typically, pythonservice.exe). When this data
            makes it to the child process, the prepare() function will treat
            main_path as a path to a python module, and will try to import it.
            This causes it to fail.
            My quick-and-dirty solution was to check in get_preparation_data() if
            main_path ends with '.exe', and if it does, to not pass it at all.
            This solves the problem in my case, but perhaps there's a better way
            to fix this? Here is my version of get_preparation_data():
            def get_preparation_data(name):
                '''
                Return info about parent needed by child to unpickle process
            object
                '''
                from .util import _logger, _log_to_stderr
                d = dict(
                    name=name,
                    sys_path=sys.path,
                    sys_argv=sys.argv,
                    log_to_stderr=_log_to_stderr,
                    orig_dir=process.ORIGINAL_DIR,
                    authkey=process.current_process().authkey,
                    )
                if _logger is not None:
                    d['log_level'] = _logger.getEffectiveLevel()
                if not WINEXE:
                    main_path = getattr(sys.modules['__main__'], '__file__', None)
                    if not main_path and sys.argv[0] not in ('', '-c'):
                        main_path = sys.argv[0]
                    if main_path is not None:
                        if not os.path.isabs(main_path) and \
                                                  process.ORIGINAL_DIR is not
            None:
                            main_path = os.path.join(process.ORIGINAL_DIR,
            main_path)
                        if not main_path.endswith('.exe'):
                            d['main_path'] = os.path.normpath(main_path)
                return d

            posted on 2010-01-27 17:51 margin 閱讀(257) 評論(0)  編輯 收藏 引用 所屬分類: Pathon
            <2025年7月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            常用鏈接

            留言簿

            隨筆檔案

            文章分類

            文章檔案

            收藏夾

            常去的壇子

            • CVC電腦病毒論壇
            • 很多人說我是AV,我告訴他們:別瞧不起人,我們也能創造價值
            • 安全焦點
            • 黑客聚集的地方,一般是好酒最多的地方...
            • 看雪論壇
            • 國內最強的加密解密論壇,成醉其中經常夜不歸宿
            • 驅動開發論壇
            • 厭倦了啤的朋友們,來我們來整點白的...痛痛快快的BSOD也好過隔鞋瘙癢!

            我的朋友

            • Sen的blog
            • IDE方面資深的受害者...經常為一個變量的定義找不著北的痛苦程序員(深表同情)
            • 老羅的blog
            • 良師益友,千年水牛,引擎猛男,分析怪獸,墨鏡酷哥,臺球高手....

            搜索

            •  

            最新評論

            jizzjizz国产精品久久| 久久久久亚洲AV成人网| 免费精品国产日韩热久久| 久久天天躁狠狠躁夜夜av浪潮 | 国产99久久久国产精免费| 99久久777色| 色综合久久天天综线观看| 精品国产日韩久久亚洲| 俺来也俺去啦久久综合网| 久久综合九色欧美综合狠狠| 久久久久亚洲AV无码专区首JN| 中文字幕人妻色偷偷久久| 国产午夜精品理论片久久影视| 三级韩国一区久久二区综合 | 久久精品国产91久久麻豆自制| 91精品国产色综合久久| 伊人久久无码精品中文字幕| 97久久精品无码一区二区| 久久无码一区二区三区少妇| 久久天天躁狠狠躁夜夜网站| 久久久久久国产精品免费免费| 天堂久久天堂AV色综合| 久久久无码精品午夜| 久久夜色tv网站| 久久久久久国产精品免费无码| 无码人妻少妇久久中文字幕| 99久久人妻无码精品系列蜜桃 | 久久九九免费高清视频| 久久精品黄AA片一区二区三区| 久久噜噜久久久精品66| 99久久这里只有精品| 人妻无码中文久久久久专区| 久久久久亚洲av综合波多野结衣| 久久久久国产亚洲AV麻豆| 久久99国内精品自在现线| 亚洲精品无码久久一线| 久久久精品人妻一区二区三区蜜桃| 久久久无码精品午夜| 久久精品亚洲男人的天堂| 91久久精品国产成人久久| 老司机国内精品久久久久|