• <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 閱讀(253) 評論(0)  編輯 收藏 引用 所屬分類: Pathon
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿

            隨筆檔案

            文章分類

            文章檔案

            收藏夾

            常去的壇子

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

            我的朋友

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

            搜索

            •  

            最新評論

            久久综合综合久久综合| 久久久久AV综合网成人| 精品久久久无码中文字幕天天| 亚洲国产精品久久66| 国产香蕉久久精品综合网| 亚洲av成人无码久久精品 | 国产精品久久久久jk制服| 久久国产精品久久国产精品| 欧美粉嫩小泬久久久久久久 | 亚洲精品乱码久久久久久蜜桃图片| 久久综合久久自在自线精品自 | 久久99国产精品久久久| 精品久久久久久久久久中文字幕 | 2021国内久久精品| 久久久www免费人成精品| 精品久久久久久亚洲| 久久久久久久久波多野高潮| 久久综合久久综合九色| 亚洲精品乱码久久久久久蜜桃不卡| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 久久人人超碰精品CAOPOREN| 亚洲精品国产综合久久一线| 久久99精品久久久久久| 久久亚洲精品成人av无码网站 | 国色天香久久久久久久小说| 国产高潮国产高潮久久久91| 欧美精品久久久久久久自慰| 一本综合久久国产二区| 久久中文字幕无码专区| 91精品国产高清久久久久久国产嫩草| 久久夜色精品国产噜噜噜亚洲AV | 国产成人久久精品二区三区| 精品久久一区二区| 国内精品久久久久| 久久91精品国产91久久户| 久久99久久99精品免视看动漫| 国色天香久久久久久久小说| 午夜不卡久久精品无码免费| 性欧美丰满熟妇XXXX性久久久 | 精品久久久无码中文字幕天天| 波多野结衣中文字幕久久 |