• <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
            • 良師益友,千年水牛,引擎猛男,分析怪獸,墨鏡酷哥,臺球高手....

            搜索

            •  

            最新評論

            亚洲色大成网站WWW久久九九| 久久婷婷五月综合97色直播| 亚洲中文精品久久久久久不卡| 久久久亚洲欧洲日产国码是AV| 一本久道久久综合狠狠爱| 色综合久久无码五十路人妻| 国产一区二区精品久久| 超级碰久久免费公开视频| 久久亚洲天堂| 久久亚洲AV成人无码电影| 国产精品综合久久第一页| 精品久久久久久国产| 一级做a爰片久久毛片人呢| 久久亚洲精品国产精品婷婷| 国产69精品久久久久9999APGF | 久久亚洲AV成人无码| 日韩精品久久无码中文字幕| 久久久精品人妻无码专区不卡| 7777精品久久久大香线蕉| 久久久久国产精品麻豆AR影院| 色狠狠久久AV五月综合| 久久久亚洲裙底偷窥综合| 看全色黄大色大片免费久久久| 久久精品一区二区| 亚洲国产精品久久久天堂| 香港aa三级久久三级老师2021国产三级精品三级在 | 亚洲国产成人久久综合区| 嫩草影院久久99| 久久天堂AV综合合色蜜桃网| 伊人久久大香线蕉成人| 久久精品国产99国产精品| 青青草原综合久久| 99久久99久久久精品齐齐| 亚洲国产另类久久久精品黑人 | 无码人妻精品一区二区三区久久久| 久久夜色撩人精品国产小说| 久久香蕉国产线看观看乱码| 国产精品99久久免费观看| 色婷婷综合久久久中文字幕| 无码人妻久久一区二区三区| 久久精品一本到99热免费|