• <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 閱讀(256) 評論(0)  編輯 收藏 引用 所屬分類: Pathon
            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            常用鏈接

            留言簿

            隨筆檔案

            文章分類

            文章檔案

            收藏夾

            常去的壇子

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

            我的朋友

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

            搜索

            •  

            最新評論

            91麻豆精品国产91久久久久久| 九九久久99综合一区二区| 91久久香蕉国产熟女线看| 久久久久久亚洲精品无码| 一本综合久久国产二区| 国内精品久久国产| 亚洲va中文字幕无码久久不卡| 久久久亚洲欧洲日产国码二区 | 国产精品99精品久久免费| 丰满少妇高潮惨叫久久久| 精品国产青草久久久久福利| 99久久综合狠狠综合久久| 7777精品伊人久久久大香线蕉 | 99久久亚洲综合精品网站| 久久最新免费视频| 国内精品久久久久影院薰衣草 | 久久久久亚洲av成人网人人软件| 久久成人国产精品免费软件| 国产精品99久久精品| 97香蕉久久夜色精品国产| 久久久久99精品成人片 | 久久AAAA片一区二区| 亚洲Av无码国产情品久久| 久久精品国产网红主播| 久久精品国产免费观看| 久久一区二区免费播放| 国产高清国内精品福利99久久| 99久久99久久| 日韩乱码人妻无码中文字幕久久| 国产巨作麻豆欧美亚洲综合久久| 久久精品亚洲精品国产色婷| 久久久国产打桩机| 亚洲婷婷国产精品电影人久久| 久久本道久久综合伊人| 亚洲国产精品久久久久婷婷老年| 国产精品久久久久国产A级| 亚洲人成网亚洲欧洲无码久久| 久久99国产一区二区三区| 久久99国产精品尤物| 久久婷婷五月综合97色一本一本| 麻豆亚洲AV永久无码精品久久|